summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Zap a trailing spacetb2024-12-051-2/+2
|
* Make the DSS_prime_checks macro internaltb2024-12-052-11/+12
| | | | | | | | Rename it to DSA_prime_checks and add an XXX comment mentioning that we could reduce the number of rounds thanks to BPSW. There are no plans of changing that as DSA is on its way out. discussed with miod
* Remove the undocumented DSA_is_prime() macrotb2024-12-051-3/+1
| | | | | | It aliases BN_is_prime(), which was removed in April 2023. makes sense to miod
* document the #define'd constant PKCS5_SALT_LENschwarze2024-12-051-4/+6
|
* drop comments asking for documentation of three ASN1_PKEY_CTRL_CMS_*schwarze2024-12-051-5/+2
| | | | | constants after these have been marked as intentionally undocumented; they are internal to the library and unused in the wild
* Apply a little bit of lipstick to PKCS7tb2024-12-051-3/+7
| | | | | | | Makes the setting and getting of detached signatures more symmetric and avoids a NULL access. ok jsing
* Use ASIdentifiers rather than struct ASIdentifiers_sttb2024-12-041-2/+2
| | | | | | This matches the other members of X509 and is what's used everywhere else. ok miod
* Another now unused perlasm script can bite the dust.jsing2024-12-041-1267/+0
|
* Provide a replacement assembly implementation for SHA-1 on amd64.jsing2024-12-043-2/+345
| | | | | | | | | | | | | As already done for SHA-256 and SHA-512, replace the perlasm generated SHA-1 assembly implementation with one that is actually readable. Call the assembly implementation from a C wrapper that can, in the future, dispatch to alternate implementations. On a modern CPU the performance is around 5% faster than the base implementation generated by sha1-x86_64.pl, however it is around 15% slower than the excessively complex SSSE2/AVX version that is also generated by the same script (a SHA-NI version will greatly outperform this and is much cleaner/simpler). ok tb@
* 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.
* Meant to split the sentence in twotb2024-11-301-3/+3
|
* Be a bit more precise on the error conditions of CMS_get1_{certs,crls}()tb2024-11-301-3/+4
|
* Explain how to free the stack returned by CMS_get1_{certs,crls}()tb2024-11-301-2/+9
| | | | with job
* 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
* Don't leak the abuf on error in PKCS7_dataFinal()tb2024-11-301-1/+2
| | | | ok beck miod
* Remove X9.42 DH rudimentstb2024-11-293-19/+7
| | | | | | | | | In the unlikely event that we should ever decide to implement this after a quarter century of not needing it, we can readily put this back. Until then this is dead weight. prompted by a question by djm ok jsing
* Provide an example of signing with HMAC-SHA256 or Ed25519schwarze2024-11-291-3/+67
| | | | | | because that makes it easier to see the big picture of how EVP_PKEY_new_raw_private_key(3) is supposed to be used. Feedback and OK tb@.
* Remove weird pad member that was never set to zero after malloc() sotb2024-11-293-12/+3
| | | | | | the weird thing it was supposed to be doing couldn't possibly work. ok jsing
* Make a comment match reality bettertb2024-11-261-1/+1
| | | | | | | $i386only never existed, it should be $x86only. Replace des asm file example with an aes one since we're firmly in the third millenium. ok sthen
* 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
* Fix some inaccuracies and gaps in the paragraph i wrote about CMACschwarze2024-11-241-18/+47
| | | | | | | | | such that it becomes intelligible but not too long or prominent. In particular, don't talk about EVP_PKEY_CTX_new(3), don't forget to mention EVP_PKEY_keygen(3), mention EVP_PKEY_OP_KEYGEN, and mention how to proceed once you have the desired EVP_PKEY object in hand. Substantial feedback and OK tb@.
* 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
* Simplify endian handling in SHA-3.jsing2024-11-231-26/+5
| | | | | | | | | | Rather than having blocks of code that are conditional on BYTE_ORDER != LITTLE_ENDIAN, use le64toh() and htole64() unconditionally. In the case of a little endian platform, the compiler will optimise this away, while on a big endian platform we'll either end up with better code or the same code than we have currently. ok tb@
* 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
* Provide a SHA-256 assembly implementation for amd64 using SHA-NI.jsing2024-11-163-2/+220
| | | | | | | | This provides a SHA-256 assembly implementation for amd64, which uses the Intel SHA Extensions (aka SHA New Instructions or SHA-NI). This provides a 3-5x performance gain on some Intel CPUs and many AMD CPUs. ok tb@
* Remove sha512-x86_64.pl.jsing2024-11-161-347/+0
| | | | | Now that we have replacement SHA-256 and SHA-512 assembly implementations for amd64, sha512-x86_64.pl can go the way of the dodo.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 08:40:50 +0000