| Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is a wrapper that is the reverse of ec_point_to_octets(). It is a
bit simpler since EC_POINT_oct2point() expects the point to be allocated
already. It also hands back the correctly parsed point conversion form
so that we don't have to do this by hand in a few places.
ok jsing
|
|
This can do the reverse dance: chain BN_hex2bn() with EC_POINT_bn2point().
ok jsing
|
|
Instead of doing everything by hand, this can use EC_POINT_point2bn()
and chain it with BN_bn2hex(), slashing the number of lines in half.
This removes one of the ten remaining "01234567890ABCDEF" strings from
libcrypto. Unfortunately, none of the nine others is used in an API that
could convert the octet string directly, so we use that ugly detour via
a bignum. Still it's better than what was there.
ok jsing
|
|
While it makes little sens to place either one of the uncompressed, the
compressed or the hybrid X9.62 octet string encoding of an elliptic curve
point into a BIGNUM, it is what this API does. It's ec_point_to_octets()
followed by BN_bin2bn().
ok jsing
|
|
Garbage collect the ok variable and some comments from captain obvious,
wrap a long line and tidy up the exit path.
|
|
|
|
|
|
This adds a specialized helper for creating an ASN.1 bit string
out of an elliptic curve point (the public key) and use it in
i2d_ECPrivateKey().
ok jsing
|
|
This adds a specialized helper for creating an ASN.1 octet string
out of an elliptic curve point (the generator). Use this to simplify
ec_asn1_group2parameters().
ok jsing
|
|
EC_POING_point2oct() is annoying to use since its invocation involves
two calls: one to determine the space to allocate and one to pass the
buffer and perform the actual conversion. Wrap this dance in a helper
with the correct signature.
ok jsing
|
|
|
|
EC_KEY_set_public_key() sets a copy, so it doesn't take ownership and
hence pub_key must not be nulled out on success.
|
|
(will be fixed shortly).
|
|
Can't replace it with adding the point to itself since that also leaks
(another doc bug). Who would've thought.
|
|
|
|
|
|
|
|
The private key is a random integer between 1 and order - 1. As such it
requires at most as many bytes as the order to encode. SEC 1, Section C.4
is very explicit about padding it to this length:
The component privateKey is the private key defined to be the octet
string of length [ceil(log_2 n/8)] (where n is the order of the curve)
obtained from the unsigned integer via the encoding of Section 2.3.7.
Fix this by generalizing a similar fix for field elements.
ok jsing
|
|
If the public key is not part of the ECPrivateKey, it needs to be
computed. Rather than doing this ad hoc inline, use the function
from the ameth that already does this.
If it is present, decode it after checking that its unused bits octet
is zero. Again use the dedicated setter API to honor an eventual
EC_KEY_METHOD.
There remains a gross bit reading the point point conversion form out of
the first octet of the bit string. This will go away in a later commit.
ok jsing
|
|
This helper will be needed in a subsequent commit.
ok jsing
|
|
Contrary to domain parameters and public key, the private key most be
part of the DER. Convert that to a BIGNUM and set it on the EC_KEY.
Use the dedicated setter for this (which will possibly call the handler
of the EC_KEY_METHOD) rather than doing this by hand.
ok jsing
|
|
In order to decode a private key, the group must be known in some way.
Typically, the group is encoded in the EC domain parameters, preferably
as a named curve (this is mandatory in PKIX per RFC 5480).
However, the group could be absent because the domain parameters are
OPTIONAL in the ECPrivateKey SEQUENCE. In that case the code falls
back to the group that may already be set on the EC_KEY. Now there is
no way to tell whether that group is the right one...
In any case. Split this thing out of the body of d2i_ECPrivateKey()
to make that function a bit less of an eyesore.
ok jsing
|
|
|
|
|
|
It doesn't currently need ec_local.h, but it will soon, so leave it there.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reduces an upcoming diff which is hard enough to review without these
distractions.
|
|
|
|
|
|
|
|
Of course the four stunning beauties in there aren't printing anything.
the hex family converts an elliptic curve point's X9.62 encoding into a
hex string (which kind of makes sense, you can print that if you want).
Much more astounding is EC_POINT_point2bn() where the X9.62 octet string
is interpreted as a BIGNUM. Yes, the bignum's hex digits are the point
conversion form followed by the affine coordinate(s) of the elliptic
curve point, and yes you can choose between compressed, uncompressed,
and hybrid encoding, why do you ask? This doesn't really make any sense
whatsoever but of course you can also print that if you really want to.
Of course the beloved platinum members of the "gotta try every terrible
OpenSSL interface" club had to use and expose this.
|
|
This can't be perfectly symmetric, but the logic is now roughly the same
in both these functions.
|
|
|
|
|
|
No need to guard free() with a NULL check, check explicitly against 0
and rename p to seed.
|
|
|
|
Some test cases are disabled since they exercise an upcoming bug fix.
|
|
|
|
CID 511280
|
|
|
|
point to an octet string and match with the initial octet string.
would have caught the regression found by anton
|
|
This is annoying since it undoes some polishing done before commit and
reintroduces an unpleasant asymmetry.
found by anton via openssl-ruby tests
ok jsing
|
|
... is obviously r.
|
|
|
