summaryrefslogtreecommitdiff
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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@.
* Mark six EVP_PKEY control constants as intentionally undocumentedschwarze2024-11-291-0/+4
| | | | | that are only intended for internal use, do very little (only validity checking), are unused in the wild, and marked obsolete in OpenSSL 3.
* Mark nine unused EVP constants as intentionally undocumented.schwarze2024-11-291-5/+10
| | | | Fix related indentation while here.
* 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 regression tests for small builtin curvestb2024-11-244-5/+29
|
* 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.
* Provide a replacement assembly implementation for SHA-512 on amd64.jsing2024-11-163-6/+336
| | | | | | | | Replace the perlasm generated SHA-512 assembly with a more readable version and the same C wrapper introduced for SHA-256. As for SHA-256, on a modern CPU the performance is largely the same. ok tb@
* Add CPU capability detection for the Intel SHA extensions (aka SHA-NI).jsing2024-11-162-5/+27
| | | | | | | This also provides a crypto_cpu_caps_amd64 variable that can be checked for CRYPTO_CPU_CAPS_AMD64_SHA. ok tb@
* Specify size for K256 symbol.jsing2024-11-161-1/+2
| | | | Missing sizes spotted by guenther@
* Merge ec_kmeth into ec_keytb2024-11-163-331/+272
|
* 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
|
* Use a better curve and a better hash for the ECDSA_do_sign() exampletb2024-11-151-9/+9
| | | | (Many examples in this directory are really bad. This is no exception.)
* 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
* x509_policy.c: point at RFC 9618tb2024-11-141-3/+3
|
* 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
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-28 02:42:51 +0000