summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* ec_asn1_group2parameters: replace point with generatortb2024-10-301-4/+4
|
* ec_asn1_group2parameters: mechanically replace ret with parameterstb2024-10-301-15/+15
|
* Provide ec_point_to_asn1_bit_string()tb2024-10-301-30/+14
| | | | | | | | 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
* Provide ec_point_to_asn1_octet_string()tb2024-10-301-26/+49
| | | | | | | | 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
* Add a convenience wrapper for EC_POINT_point2oct()tb2024-10-302-2/+48
| | | | | | | | | 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
* Split ec_key_test_point_encoding() into chunks of saner sizetb2024-10-291-49/+172
|
* eckey_compute_pubkey: don't leak the public keytb2024-10-291-2/+1
| | | | | 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.
* ec_asn1_test: point doubling is fine, the leak is elsewheretb2024-10-291-3/+1
| | | | (will be fixed shortly).
* Disable point doubling for now, it leaks due to a doc bug.tb2024-10-291-1/+3
| | | | | Can't replace it with adding the point to itself since that also leaks (another doc bug). Who would've thought.
* ec_asn1: zap an empty linetb2024-10-291-2/+1
|
* unifdef -m -DCORRECT_PRIV_KEY_PADDING=1 ec_asn1_test.ctb2024-10-281-9/+1
|
* Enable the tests that depend on correct private key paddingtb2024-10-281-2/+2
|
* Fix private key encoding in i2d_ECPrivateKey()tb2024-10-281-31/+40
| | | | | | | | | | | | | | 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
* d2i_ECPrivateKey: split public key setting into a helpertb2024-10-281-36/+41
| | | | | | | | | | | | | | | 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
* Expose eckey_compute_key() from ec_amethtb2024-10-282-3/+4
| | | | | | This helper will be needed in a subsequent commit. ok jsing
* d2i_ECPrivateKey: split private key setting into a helpertb2024-10-281-14/+31
| | | | | | | | | 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
* d2i_ECPrivateKey: split parameter setting into a helpertb2024-10-281-8/+26
| | | | | | | | | | | | | | | | 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
* Rename the EC_KEY in i2o_ECPublicKey() to ec_keytb2024-10-281-6/+6
|
* Rename the EC_KEY in i2d_ECPrivateKey() to ec_keytb2024-10-281-14/+14
|
* ec_print.c: fix includes.tb2024-10-281-2/+6
| | | | It doesn't currently need ec_local.h, but it will soon, so leave it there.
* c2sp: run test against openssl/3.4 if it is installedtb2024-10-281-2/+2
|
* d2i_ECParameters: clean up entry and exittb2024-10-271-13/+17
|
* d2i_ECParameters: rename a to out_ec_keytb2024-10-271-7/+7
|
* d2i_ECParameters: rename ret to ec_keytb2024-10-271-9/+9
|
* i2d_ECParameters: rename a to ec_keytb2024-10-271-4/+4
|
* {d2i,i2d}_ECParameters() also want a bit of exercisingtb2024-10-261-1/+28
|
* d2i_ECPrivateKey: move the version setting where it belongstb2024-10-261-2/+2
|
* d2i_ECPrivateKey: minor cleanup for entry and exit pathtb2024-10-261-13/+13
| | | | | Reduces an upcoming diff which is hard enough to review without these distractions.
* a and ret aren't great names for EC_KEYstb2024-10-261-26/+26
|
* Mechanically rename priv_key to ec_privatekeytb2024-10-261-27/+27
|
* ec_asn1_test: play some silly games to cover a few more code pathstb2024-10-261-1/+47
|
* Add regress coverage for ec_print.ctb2024-10-261-2/+889
| | | | | | | | | | | | | | | | | 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.
* Cosmetic tweak to make point2oct and oct2point more symmetrictb2024-10-251-7/+12
| | | | | This can't be perfectly symmetric, but the logic is now roughly the same in both these functions.
* Use macros describing the intent rather than #if 0tb2024-10-251-8/+38
|
* ec_asn1: make two helpers statictb2024-10-251-3/+3
|
* Minor cosmetic tweaks for EC_GROUP_set_seed()tb2024-10-251-9/+8
| | | | | No need to guard free() with a NULL check, check explicitly against 0 and rename p to seed.
* ec_asn1: fix some NULL misspellingstb2024-10-251-4/+4
|
* Add regress for {d2i,i2d}_ECPrivateKey() and {o2i,i2o}_ECPublicKey()tb2024-10-251-1/+1003
| | | | Some test cases are disabled since they exercise an upcoming bug fix.
* Fix argument names: des_in -> der_in and des_out -> der_outtb2024-10-242-19/+19
|
* Add missing error check for CBB_init_fixed()tb2024-10-241-4/+5
| | | | CID 511280
* ec_point_conversion: cosmeticstb2024-10-231-4/+4
|
* ec_point_conversion: extend test coverage by translating back thetb2024-10-231-2/+76
| | | | | | point to an octet string and match with the initial octet string. would have caught the regression found by anton
* EC_POINT_point2oct() need to special case the point at infinitytb2024-10-231-4/+10
| | | | | | | | 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
* EC_get_builtin_curves(): the most appropriate name for a list of curves...tb2024-10-231-5/+5
| | | | ... is obviously r.
* remove duplicate defines; ok tb@jsg2024-10-233-13/+3
|
* remove duplicate X509v3_asid_add_id_or_range.3 linejsg2024-10-221-2/+1
|
* Move a check for hybrid point encoding into a helper functiontb2024-10-221-7/+14
|
* Rewrite ec_GFp_simple_point2oct() using CBBtb2024-10-221-63/+90
| | | | | | | | | | Factor ad-hoc inline code into helper functions. Use CBB and BN_bn2binpad() instead of batshit crazy skip loops and pointer banging. With all this done, the function becomes relatively streamlined and pretty much symmetric with the new oct2point() implementation. ok jsing
* Rewrite ec_GFp_simple_oct2point() using CBStb2024-10-221-57/+86
| | | | | | | | | Transform the spaghetti in here into something more readable. Factor various inline checks into helper functions to make the logic clearer. This is a bit longer but a lot safer and simpler. It accepts exactly the same input as the original version. ok jsing
* Start cleaning up oct2point and point2octtb2024-10-221-5/+41
| | | | | | | | | | | | | | | | | | | The SEC 1 standard defines various ways of encoding an elliptic curve point as ASN.1 octet string. It's also used for the public key, which isn't an octet string but a bit string for whatever historic reason. The public API is incomplete and inconvenient, so we need to jump through a few hoops to support it and to preserve our own sanity. Split a small helper function out of ec_GFp_simple_point2oct() that checks that a uint8_t represents a valid point conversion form. It supports exactly the four possible variants and helps translating from point_conversion_form_t at the API boundary. Reject the form for the point at infinity since the function has historically done that even for the case that the point actually is the point at infinity. ok jsing
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-31 23:58:00 +0000