summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/ec (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Move compressed coordinate setting into public APItb2025-01-113-108/+83
| | | | | | | | 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
* Rework ec_point_set_compressed_coordinates()tb2025-01-111-18/+14
| | | | | | | | | | While this is nicely done, it is a bit too clever. We can do the calculation in the normal domain rather than the Montgomery domain and this way the method becomes method agnostic. This will be a bit slower but since a couple of field operations are nothing compared to the cost of BN_mod_sqrt() this isn't a concern. ok jsing
* Move ec_points_make_affine() to the right placetb2025-01-111-135/+135
| | | | discussed with jsing
* Move the EC_POINTs API into the garbage bintb2025-01-111-20/+20
|
* Neuter the EC_POINTs_* APItb2025-01-114-77/+16
| | | | | | | | | | | | | | 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
* Remove a pointless check about Z == 1tb2025-01-111-7/+1
| | | | ok jsing
* Inline ec_point_make_affine() in the public APItb2025-01-113-44/+22
| | | | | | | | | | 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
* ec_lib.c: zap stray empty line at end of filetb2025-01-091-2/+1
|
* check_discriminant: make the assumptions on p, a, b more explicittb2025-01-091-2/+3
| | | | requested by jsing
* Remove stale comment about methods and memberstb2025-01-071-6/+1
|
* Check discriminant directly in EC_GROUP_set_discriminant()tb2025-01-073-68/+47
| | | | | | | | | | 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
* ec_lib: create a garbage bin at the end, throw Jprojective stuff in theretb2025-01-061-19/+24
|
* Inline the last two uses of ec_mont_group_clear()tb2025-01-061-14/+11
|
* group_copy() is no longer a thing...tb2025-01-061-3/+1
|
* Remove get_order_bits() and get_degree() methodstb2025-01-063-28/+5
| | | | | | | 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
* More dest -> dst renaming missed in previoustb2025-01-061-8/+8
| | | | requested by jsing
* Rename dest into dsttb2025-01-061-21/+21
| | | | requested by jsing
* Inline the copy handlers in EC_GROUP_copy()tb2025-01-062-51/+19
| | | | | | This is another bit of indirection that makes this code so hard to follow. ok jsing
* Use a slightly more sensible order in ec_local.htb2025-01-061-36/+33
|
* Revise comments to note that these are Jacobian projective coordinates.jsing2025-01-061-3/+6
|
* Remove indirection for coordinate blinding.jsing2025-01-063-28/+4
| | | | | | | 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-063-56/+16
| | | | | | | | | | | | 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-063-150/+16
| | | | | | | | | | | | | | | | | 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-055-194/+208
| | | | | | | | | | | | | | | | | | | | | 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-013-23/+9
| | | | | | | 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-013-37/+3
| | | | | | | | 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
* Use the shorthand p rather than &group->p in one more placetb2025-01-011-2/+2
|
* Remove disabled code supporting elliptic curves of small ordertb2024-12-241-1014/+1
| | | | ok jsing
* ec_mult: use 1ULL to avoid C4334 warning on Visual Studiotb2024-12-191-2/+2
| | | | | The shift is between 0 and 5 bits, so it doesn't matter, but VS is short for very st...ubborn as are its users when it comes to reporting non-issues
* Simplify ec_point_to_octets()tb2024-12-161-8/+3
| | | | | | | | | | | This had an extra dance to allow a NULL output buffer. The plan was to use this in i2o_ECPublicKey() to preserve the behavior of avoiding an allocation if out == NULL. However, when I rewrote the latter I punted on preserving that complication, as it was already batshit crazy enough. Thus, remove said dance and make ec_point_to_octets() cleaner. ok jsing
* Rewrite a comment to use p rather than qtb2024-12-121-10/+10
|
* Rename group->field to group->ptb2024-12-124-52/+46
| | | | | | 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.
* ec_mult: forgot to make one helper statictb2024-12-071-2/+2
|
* Move initialization of sign out of the middle of bits handlingtb2024-12-071-3/+3
|
* Rename ec_wNAF_mul() to ec_wnaf_mul()tb2024-12-063-7/+7
| | | | discussed with jsing
* ec_mult: manage wNAF data in a structtb2024-12-061-86/+131
| | | | | | | | | | | | | | | | | | | | | | This refactors the wNAF multiplication further and introduces a small API that manages the wNAF digits for bn and the multiples of digit * point in a single struct that is initialized and freed in two API calls in the main function, ec_wNAF_mul(). This way the main algorithm is no longer cluttered with logic to keep various arrays in sync, helper functions calculating the wNAF splitting of bn and multiples of the point do not need to deal with memory management, and a pair of accessors obviates previously missing bounds checking. At this point we have reached a relatively clean and straightforward wNAF implementation that fits precisely the purpose needed in libcrypto, i.e., ECDSA verification instead of being generalized and optimized to the max for no good reason apart from endowing the author with an academic degree. Popper's famous maxim "if you can't say it clearly, keep quiet, and keep working until you can" very much applies to code as well. In other words, shut up and hack (and don't pour too much energy into commit messages, tb). ok jsing
* ec_asn1: update a comment to match realitytb2024-12-061-2/+2
|
* Set nid on group decoded from EC parameterstb2024-12-063-7/+14
| | | | | | | | | | | | | 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
* Annotate WTLS7 as being wrongtb2024-12-041-1/+2
| | | | | | | This should really have been using SECP 160R2, not SECP 160R1. Of course this means in particular that nobody ever used this curve, at least not against another implementation than OpenSSL. Quasi-monocultures are poisonous whether the monopolist is benevolent and competent or not.
* Inline trivial EC point methodstb2024-11-303-95/+23
| | | | | | | | | 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
* Get BNs Z coordinates from the BN_CTXtb2024-11-301-8/+3
| | | | | | | | While there likely won't be enough BNs already available in the ctx, and thus it won't greatly reduce the amount of allocated BNs, it simplifies the exit path quite a bit. review feedback from jsing
* Improve ec_points_make_affine()tb2024-11-301-119/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It is unclear how the original code was supposed to work. It clearly missed a few corner cases (like handling points at infinity correctly) and the badly mangled comment that was supposed to display a binary search tree didn't help at all. Instead do something much more straightforward: multiply all the non-zero Z coordinates of the points not at infinity together, keeping track of the intermediate products. Then do a single expensive modular inversion before working backwards to compute all the inverses. Then the transformation from Jacobian coordinates to affine coordiantes (x, y, z) -> (x/z^2, y/z^3, 1) becomes cheap. A little bit of care has to be taken for Montgomery curves but that's very simple compared to the mess that was there before. ok jsing This is a cleaned up version of: commit 0fe73d6c3641cb175871463bdddbbea3ee0b62ae Author: Bodo Moeller <bodo@openssl.org> Date: Fri Aug 1 17:18:14 2014 +0200 Simplify and fix ec_GFp_simple_points_make_affine (which didn't always handle value 0 correctly). Reviewed-by: emilia@openssl.org
* Unify checking for the asn1_flagtb2024-11-252-4/+4
| | | | | | | | | | | There are only two flag values that libcrypto understands and the default value is 1 while, helpfully, the undesirable non-default is 0. The few existing callers set OPENSSL_EC_NAMED_CURVE or OPENSSL_EC_EXPLICIT_CURVE. Nevertheless, the flag should be checked properly as a flag. The recent upstream checks for EC_GROUP_get_asn1_flag(group) == OPENSSL_EC_NAMED_CURVE don't look right either... ok jsing
* Disable small builtin curvestb2024-11-241-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | This disables all the curves over fields < 224 bits and a few others. Specifically: SECG: 112r1 112r2 128r1 128r2 160k1 160r1 160r2 192k1 192r1 192v{1,2,3} WTLS: 6 7 8 9 12 Brainpool: P160r1 P160t1 P192r1 P192t1 These are below or at the limit of what is acceptable nowadays. This is less aggressive than what some enterprise linux distributions are using in their patched OpenSSL versions where everything over fields < 256 bits is disabled with the exception of P-224, so interoperability should not be a problem. The curves are left in the tree for now and can be re-enabled by compiling libcrypto with -DENABLE_SMALL_CURVES. They will be fully removed later. One nice benefit of doing this is that the incorrect parameters for WTLS 7 are fixed (obviously nobody uses this one) and now all the builtin curves have a unique corresponding OID (nid). Something like this was suggested a while back by beck, makes sense to sthen ok jsing
* Further refactoring of the wNAF codetb2024-11-231-55/+65
| | | | | | | | | | | | | | | | | | | The big change is that the "rows" are no longer slices of val[] but that they actually own the points they contain. The price for this is an extra allocation for val[] and to piece it together from the two rows. That's ugly, but less ugly than before. Add a helper for freeing a row of points. It can deal with a NULL row so, we can remove a couple of complications. The second change is that the logic for preparing the rows is pulled back into ec_wNAF_mul[]. This way the m * G + n * P logic is in the one function that needs to know about it, the rest just deals with a pair of a point and a scalar. This starts resembling actual code... ok jsing
* Drop bn is zero special casetb2024-11-231-5/+1
| | | | | | | | This is a corner case that isn't really of interest. We're making a few calculations that don't really hurt, but it's super cheap, so one more complication bites the dust. ok jsing
* Further simplify after dropping wNAF modificationtb2024-11-231-23/+13
| | | | | | | | We can now turn the for loop into a proper for loop for which there is obviously no out of bounds access. The length can be determined up front and it's easier to explain what's going on, so expand a few comments. ok jsing
* Ditch the wNAF modificationtb2024-11-231-10/+5
| | | | | | | | | | | This is another micro optimization that introduces needless complications for the sake of saving a few cycles. Specifically, by ditching the rule defining the wNAF representation (at most one of w+1 consecutive digits is non-zero) for the topmost digits, one can sometimes save a few digits at the cost of crazy loop conditions and other weirdness. That's not worth it. ok jsing
* Comment tweak from jsing with another tweak by metb2024-11-221-2/+2
|
* Stop using BIGNUM internals, add some clarifying commentstb2024-11-221-4/+23
| | | | ok jsing
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-21 16:36:54 +0000