summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/ec (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Rewrite the crazy while loop into a for looptb2024-11-221-5/+5
| | | | | | It's still horrible, but slightly less so... ok jsing
* First pass over compute_wNAF()tb2024-11-221-145/+80
| | | | | | | | This streamlines this mess and adapts the API better to its only caller. Nothing much going on here, except that we drop confusing checks and unhelpful comment, thereby making the algorithm more cleanly visible. ok jsing
* Swap the order of m and n in ec_wNAF_precompute()tb2024-11-221-10/+10
| | | | | | This matches the ec_wNAF_mul() API better ok jsing
* Split two helpers out of ec_wNAF_mul()tb2024-11-221-92/+119
| | | | | | | | | | | | | | | | | | | | As its name indicates, the first, ec_compute_odd_multiples(), fills point, 3 * point, 5 * point, ..., (2 * len - 1) * point into row[]. In fact, it first computes doubled = 2 * point and then goes on to set row[i] = row[i - 1] + doubled. That's straightforward enough. One change here is that this helper allocates row[i] on the fly rather than preallocating the entire array of points up front. The second piece is the actual precomputation, ec_wNAF_precompute(). It first computes the wNAF digits of the two scalars n and m (in this order for now) with appropriate window size and length. Then the above mentioned val[] array is allocated and populated with odd multiples of point and generator. Finally, all points in val[] are made affine in a single step, which means we only need one modular inversion, and this then allows us to take fast paths in all the computations in the one remaining loop in ec_wNAF_mul(). ok jsing
* Rename curve_name into nidtb2024-11-222-6/+6
| | | | | | 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.
* Use OPENSSL_EC_EXPLICIT_CURVE rather than 0tb2024-11-221-2/+2
|
* Garbage collect the now unused totalnumtb2024-11-221-5/+2
|
* Move wNAF[], wNAF_len[], wsize[] to the stacktb2024-11-221-32/+6
| | | | | | | Again, we know their sizes (always 2), so we can avoid allocating and freeing them. Also remove the extra "pivot" element. It's not needed. ok djm
* Change 0 - digit to -digittb2024-11-221-2/+2
| | | | pointed out by jsing
* Rename val_sub[] into row[] and move it to the stacktb2024-11-221-15/+13
| | | | ok djm
* ec_wNAF_mul(): lose two levels of indentationtb2024-11-211-17/+18
| | | | | | This makes the mess a bit more readable. ok jsing
* ec_wNAF_mul(): remove r_is_at_infinity sillinesstb2024-11-211-25/+20
| | | | | | | | | | All the EC_POINT_* API has a fast path for the point at infinity. So we're not gaining more than a few cycles by making this terrible mess even more terrible than it already is by avoding calls ot it (it's also incorrect as it is since we don't know that the point is no longer at infinity when it is unset). Simplify and add a comment explaining what this mess is doing. ok jsing
* ec_lib: zap a useless commenttb2024-11-171-3/+1
|
* Minor simplifications in ec_cmp()tb2024-11-171-11/+9
|
* Rewrite EC_GROUP_cmp()tb2024-11-171-51/+75
| | | | | | | | | | Use better variable names (cf. https://jmilne.org/math/tips.html#4) and avoid the weird style of assigning to r (what does r stand for anyway?) and short circuiting subsequent tests using if (r || ...). Also, do not reuse the variables for order and cofactor that were previously used for the curve coefficients. ok jsing
* Simplify signature of ec_wNAF_mul()tb2024-11-163-56/+30
| | | | | | | | | | | | | 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
* Merge ec_kmeth into ec_keytb2024-11-162-329/+271
|
* Shuffle the global default_ec_key_meth down a few linestb2024-11-161-3/+3
|
* Move the default EC_KEY_METHOD to the end of the filetb2024-11-161-50/+50
|
* ec_mult: fix includestb2024-11-151-2/+5
|
* EC_KEY_copy() don't leave stale private keys in placetb2024-11-151-6/+3
| | | | | | | | | | | | As most other objects, EC_KEYs can be as sparsely and invalidly populated as imagination permits and the competent designers of EC_KEY_copy() chose to just copy over what's available (yeah, what kind of copy is that?) and leave in place what happens to be there. In particular, if the dest EC key was used with a different group and has a private key, but the source key doesn't, the dest private key remains intact, as invalid, incompatible and unusable as it may be. Fix this by clearing said private key. ok jsing
* eck_prn: some more air to breathetb2024-11-141-1/+3
|
* eck_prn: fix includestb2024-11-141-2/+4
|
* ec_prn: use pkey rather than pk for an EC_KEYtb2024-11-141-11/+11
|
* eck_prn: use group rather than x for an EC_GROUPtb2024-11-141-3/+3
|
* eck_prn: use ec_key rather than x for an EC_KEYtb2024-11-141-9/+9
|
* eck_prn: consistently use bio for a BIO rather than b and bp randomlytb2024-11-141-43/+43
|
* eck_prn: sprinkle some empty lines and drop some parens for consistencytb2024-11-141-7/+23
|
* eck_prn: shuffle printing functions into a better ordertb2024-11-141-47/+47
|
* Garbage collect a reference to ecp_mont.c, rewrap commenttb2024-11-121-7/+6
| | | | spotted by jsing
* ecp_methods.c: rewrap some linestb2024-11-121-25/+25
|
* Lose the ugly GFp_simple_ and GFp_mont_ infixestb2024-11-121-127/+117
|
* Make ec_GFp_simple_* statictb2024-11-122-71/+32
| | | | | 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.
* Merge ecp_mont.c into ecp_methods.ctb2024-11-122-271/+205
|
* KNF nit for end of comment markertb2024-11-121-2/+2
|
* Rename ecp_smpl.c to ecp_methods.ctb2024-11-121-1/+1
| | | | | | | | While not the greatest of names, ecp_methods.c is better than ecp_smpl.c. It matches the naming ecx_methods.c and in a subsequent commit it will become the new home of the stuff in ecp_mont.c as well. discussed with jsing
* Wrap comment badly mistreated by an autoformatter due to missing /*-tb2024-11-101-3/+6
|
* Garbage collect an unused variabletb2024-11-101-3/+1
|
* Clean up EC_KEY_dup()tb2024-11-081-10/+15
| | | | | | | | | This calls init() with the default method, so EC_KEY_copy() gets a chance to call finish() if the source's method doesn't match. But no init() call is made in EC_KEY_copy(). Of course the source method's copy() needs to be able to cope. The great news is that ssh uses this. Sigh. ok beck jsing
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-26 19:02:25 +0000