summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/ec/ec_local.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Explicitly pass group generator to mul_double_nonct() from EC_POINT_mul().jsing8 days1-6/+7
| | | | | | | | | | | | | | | | | | EC_POINT_mul() has a complex multi-use interface - there are effectively three different ways it will behave, depending on which arguments are NULL. In the case where we compute g_scalar * generator + p_scalar * point, the mul_double_nonct() function pointer is called, however only g_scalar, p_scalar and point are passed - it is expected that the lower level implementation (in this case ec_wnaf_mul()) will use the generator from the group. Change mul_double_nonct(), ec_mul_double_nonct() and ec_wnaf_mul() so that they take scalar1, point1, scalar2 and point2. This removes all knowledge of g_scalar and the generator from the multiplication code, keeping it limited to EC_POINT_mul(). While here also consistently pass scalar then point, rather than a mix of scalar/point and point/scalar. ok tb@
* Unexport EC_METHOD and all API using ittb2025-03-091-3/+6
| | | | | | | | | | | | This is an implementation detail and there is no reason to leak it from the library. This removes EC_GFp_{mont,simple}_method(), EC_GROUP_{method_of,new}(), EC_METHOD_get_field_type(), EC_POINT_method_of() from the public API. EC_GROUP_copy() is now quite useless, so it will go as well. ok jsing
* Garbage collect field_type member of the EC methodstb2025-01-251-3/+1
| | | | ok jsing
* Remove now unused internal ec_group_get_field_type()tb2025-01-251-2/+1
| | | | ok jsing
* Remove the mul_generator_ct function pointer from EC_METHOD.jsing2025-01-221-3/+1
| | | | | | | | | There's no need for a separate mul_generator_ct() function pointer - we really only need mul_single_ct() and mul_double_nonct(). And rather than calling ec_mul_ct() and having it figure out which point to use, explicitly pass the generator point when calling mul_single_ct(). ok tb@
* ec_key_gen() is unused outside ec_key.c, so make it statictb2025-01-111-2/+1
|
* Move EC_KEY_METHOD_DYNAMIC next to the two methods using ittb2025-01-111-3/+1
| | | | | Only EC_KEY_METHOD_{new,free}() need to know about this flag, so make that more obvious.
* Remove a weird commenttb2025-01-111-5/+1
|
* Rename the is_on_curve() method to point_is_on_curve()tb2025-01-111-2/+2
| | | | | Rename ec_is_on_curve() to ec_point_is_on_curve() and ec_cmp() to ec_point_cmp().
* Move is_on_curve() and (point) cmp() uptb2025-01-111-5/+5
| | | | | These were in the middle of the methods responsible for curve operations, which makes little sense.
* Move compressed coordinate setting into public APItb2025-01-111-3/+1
| | | | | | | | Now that it is method-agnostic, we can remove the method and move the implementation to the body of the public API function. And another method goes away. We're soon down to the ones we really need. discussed with jsing
* Neuter the EC_POINTs_* APItb2025-01-111-10/+5
| | | | | | | | | | | | | | EC_POINTs_mul() was only ever used by Ruby and they stopped doing so for LibreSSL when we incorporated the constant time multiplication work of Brumley et al and restricted the length of the points array to 1, making this API effectively useless. The only real reason you want to have an API to calculate \sum n_i P_i is for ECDSA where you want m * G + n * P. Whether something like his needs to be in the public API is doubtful. EC_POINTs_make_affine() is an implementation detail of EC_POINTs_mul(). As such it never really belonged into the public API. ok jsing
* Inline ec_point_make_affine() in the public APItb2025-01-111-2/+1
| | | | | | | | | | Whatever the EC_METHOD, this will always be equivalent to getting and setting the affine coordinates, so this needs no dedicated method. Also, this is a function that makes no real sense since a caller should never need to care about this... As always, our favorite language bindings thought they might have users who care. This time it's Ruby and Perl. ok jsing
* Remove stale comment about methods and memberstb2025-01-071-6/+1
|
* Check discriminant directly in EC_GROUP_set_discriminant()tb2025-01-071-3/+1
| | | | | | | | | | After possibly decoding a and b in EC_GROUP_get_curve(), this is a pure calculation in GFp and as such doesn't make use of any method-specifics. Let's perform this calculation directly in the public API implementation rather than redirecting through the methods and remove yet another method handler. ok jsing
* group_copy() is no longer a thing...tb2025-01-061-3/+1
|
* Remove get_order_bits() and get_degree() methodstb2025-01-061-4/+1
| | | | | | | The degree made some sense when EC2M was a thing in libcrypto. Fortunately that's not the case anymore. The order handler never made sense. ok jsing
* Use a slightly more sensible order in ec_local.htb2025-01-061-36/+33
|
* Remove indirection for coordinate blinding.jsing2025-01-061-5/+1
| | | | | | | This is usually method specific, so remove the indirection and call the appropriate blinding function directly. ok tb@
* Stop caching one in the Montgomery domaintb2025-01-061-4/+2
| | | | | | | | | | | | This is only used by ec_points_make_affine(), which is only used by the wNAF multiplication, which is only used by ECDSA. We can afford computing that one once per ECDSA verification given the cost of the rest of this. Thus, the field_set_to_one() member disappears from the EC_METHOD and the mont_one member disappears from EC_GROUP and with it all the complications when setting/copying/freeing the group. ok jsing
* Prepare removal accessors for Jprojective coordinatestb2025-01-061-10/+1
| | | | | | | | | | | | | | | | | That the BN-driven EC code uses Jacobian projective coordinates as an optimization is an implementation detail. As such this should never have leaked out of the library as part of the public API. No consumer should ever care and if they do they're doing it wrong. The only port that cares is one of those stupid little perl modules that expose all the things and transform terrible OpenSSL regress tests into similarly horrible Perl. In practice, only affine coordinates matter (perhaps in compressed form). This prunes two more function pointers from EC_GROUP and prepares the removal of the field_set_to_one() method which is now only used in ec_points_make_affine(). ok jsing sthen
* Move BIGNUMs in EC_GROUP and EC_POINT to the heaptb2025-01-051-14/+9
| | | | | | | | | | | | | | | | | | | | | The only way to get an EC_GROUP or an EC_POINT is by calling the relevant _new() function and to get rid of it, something must call _free(). Thus we can establish the invariant that every group has Weierstrass coefficients p, a, b as well as order and cofactor hanging off it. Similarly, Every point has allocated BIGNUMs for its Jacobian projective coordinates. Unfortunately, a group has the generator as an optional component in addition to seed and montgomery context/one (where optionality makes more sense). This is a mostly mechanical diff and only drops a few silly comments and a couple of unnecessary NULL checks since in our part of the wrold the word invariant has a meaning. This should also appease Coverity who likes to throw fits at calling BN_free() for BIGNUM on the stack (yes, this is actually a thing). ok jsing
* Garbage collect .group_finish()tb2025-01-011-2/+1
| | | | | | | There is only one caller, EC_GROUP_free(), so inline the relevant free calls there and dispose of a few layers of indirection. ok jsing
* Garbage collect .group_init()tb2025-01-011-2/+1
| | | | | | | | For both in-tree methods these are just complicated ways of zeroing part of the group object. The group is allocated with calloc(), so it's all entirely pointless. ok jsing
* Rename group->field to group->ptb2024-12-121-10/+5
| | | | | | Now that we only do curves over GF(p) fields, there's no need to use a weird, confusing name for what we usually call p. Adjust some comments in the vicinity as well.
* Rename ec_wNAF_mul() to ec_wnaf_mul()tb2024-12-061-2/+2
| | | | discussed with jsing
* Set nid on group decoded from EC parameterstb2024-12-061-2/+2
| | | | | | | | | | | | | We match curve parameters against the builtin curves and only accept them if they're encoding a curve known to us. After getting rid of the wtls curves, some of which used to coincide with secp curves (sometimes the wrong ones), the nid is unambiguous. Setting the nid has no direct implications on the encoding. This helps ssh avoid doing ugly computations during the key exchange for PEM keys using this encoding. ok djm joshua jsing
* Inline trivial EC point methodstb2024-11-301-11/+1
| | | | | | | | | Like most of the "group" methods these are shared between Montgomery curves and simple curves. There's no point in five methods hanging off the EC_METHODS struct whne they can just as well be inlined in the public API. It makes all files involved shorter... ok jsing
* Rename curve_name into nidtb2024-11-221-2/+2
| | | | | | This used to be the case until they were given a 'more meaningful name' about 20 years ago. We cant fix the public API, but I'm tired of being confused by this nonsense.
* Simplify signature of ec_wNAF_mul()tb2024-11-161-5/+4
| | | | | | | | | | | | | The only caller passes in num = 1 and is itself called in a path that ensures that the multiplier of the generator is != NULL. Consequently we don't need to deal with an array of points and an array of scalars so rename them accordingly. In addition, the change implies that numblocks and num_scalar are now always 1, so inline this information and take a first step towards disentangling this gordian knot. ok jsing
* Make ec_GFp_simple_* statictb2024-11-121-40/+1
| | | | | These functions are no longer shared between multiple files, so they can be static in ecp_methods.c and the long list of prototypes can go away.
* Garbage collect field_div() member.tb2024-11-011-3/+1
| | | | It was only used by EC2M.
* Retire the oct2point and point2oct EC_METHOD memberstb2024-10-311-11/+1
| | | | | | | | Both our remaining EC_METHODs use the methods that used to be called ec_GFp_simple_{oct2point,point2oct}() so there's no need for the function pointer indirection. Make the public API call them directly. ok jsing
* Provide ec_point_from_octets()tb2024-10-301-2/+4
| | | | | | | | | 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
* Add a convenience wrapper for EC_POINT_point2oct()tb2024-10-301-1/+7
| | | | | | | | | 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
* Expose eckey_compute_key() from ec_amethtb2024-10-281-1/+2
| | | | | | This helper will be needed in a subsequent commit. ok jsing
* Provide and use ec_group_get_field_type()tb2024-10-221-1/+2
| | | | | | | | | All internal uses of EC_METHOD_get_field_type() and EC_GROUP_method_of() are chained together. Implement this as a single API call that takes a group and use it throughout. Gets rid of another eyesore in this part of the tree. Not that there will be a shortage of eyesores anytime soon... ok jsing
* Enforce that EC Parameters correspond to a builtin curvetb2024-10-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | EC parameters are very general. While there are some minimal sanity checks, for the parameters due to DoS risks found in the last decade, the elliptic curve code is poorly written and a target rich environment for NULL dereferences, busy loops, expensive computations and whatever other nastiness you can think of. It is not too hard to come up with parameters that reach very ugly code. While we have removed for the worst of it (the "fast" nist code and GF2m come to mind), the code very much resembles the Augean Stables. Unfortunately, curve parameters are still in use - even mandatory in some contexts - for example in machine-readable travel documents signed by ICAO country signing certification authorities (see ICAO Doc 9303). To avoid many of these DoS vectors, start enforcing that we know what the curve parameters are about, namely that they correspond to a builtin curve. This way we know that the parameters are at least as good as the standards we implement and checking this is cheap: Translate curve parameters into the ad hoc representation in the builtin curve code and check there's a match. That's very cheap since most curves are distinguished by cofactor and parameter length and we need to use an actual parameter comparison for at most half a dozen curves, usually only one or two. ok jsing
* Provide EC_GROUP_get0_cofactor() for internal usetb2024-10-151-1/+2
| | | | | | While this is public API in OpenSSL, there are no plans to expose it. ok jsing
* Remove the unused field_mod_func from EC_GROUPtb2024-10-031-4/+1
| | | | | | | | This was only used by the NIST method. For all other group methods it's an uninitialized pointer (as EC_GROUP_new() still uses the malloc + set all members to 0 idiom). ok jsing
* Ignore ENGINE at the API boundarytb2023-11-291-2/+1
| | | | | | | | This removes the remaining ENGINE members from various internal structs and functions. Any ENGINE passed into a public API is now completely ignored functions returning an ENGINE always return NULL. ok jsing
* Stop including ecdsa.h and ecdh.h internallytb2023-07-281-2/+1
| | | | | | | | These headers are now reduced to #include <openssl/ec.h> and are provided for compatiblity only. There's no point in using them. At the same time garbage collect the last uses of OPENSSL_NO_{ECDSA,ECDH} in our tree. ok jsing
* Move KDF handling to ECDH_compute_key()tb2023-07-281-5/+5
| | | | | | | | | | In OpenSSL e2285d87, the KDF handling was moved from the compute_key() method into the public API. A consequence of this change is that the ECDH_compute_key() API no longer returns -1 for some errors. Existing checks for <= 0 are safe as are those checking for the exact length as return value, which is all what the ecosystem seems to be doing. ok jsing
* Drop useless ossl_ prefixestb2023-07-051-5/+5
| | | | discussed with jsing
* Provide internal-only EC_GROUP_get0_order()tb2023-07-031-1/+4
| | | | ok jsing
* Remove the now unused poly[] from EC_GROUPtb2023-06-271-15/+2
| | | | | | | This was needed for defining the multiplication over binary fields. Since that code is gone, this is no longer needed. ok jsing
* Remove prototypes for EC_KEY_{get,insert}_key_method_data()tb2023-06-251-8/+1
| | | | These were accidentally left behind in a previous commit.
* Move ecdh_KDF_X9_63() to ec_local.htb2023-06-251-1/+7
| | | | | In anticipation of merging ecdh/ and ecdsa/ into ec/, move the last remaining thing in ech_local.h where it will soon belong.
* Remove EC_EXTRA_DATAtb2023-06-251-26/+1
| | | | | | | | | | | With the ecdh_check() and ecdsa_check() abominations gone, we can finally get rid of EC_EXTRA_DATA and EC_KEY_{get,insert}_key_method_data(). The EC_EX_DATA_*() handlers, (which fortunately have always had "'package' level visibility") join the ride to the great bit bucket in the sky. Thanks to op for making this possible. ok jsing
* ec_local.h: move ec_group_simple_order_bits down a bittb2023-06-251-3/+2
|