summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
|
* 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
|
* AES_{decrypt,encrypt}() don't return void internal functiontb2024-11-131-3/+3
| | | | | | | "A return statement with an expression shall not appear in a function whose return type is void." ok deraadt miod
* The subject of a certificate is not optionaltb2024-11-121-2/+2
| | | | | | | | | | | | A certificate must have a subject, so X509_get_subject_name() cannot return NULL on a correctly parsed certificate, even if the subject is empty (which is allowed). So if X509_get_subject_name() returns NULL, error instead of silently ignoring it in tls_check_common_name(). This is currently no issue. Where it matters, the match against the common name will fail later, so we fail closed anyway. ok jsing
* Link the new manual page EVP_PKEY_new_CMAC_key(3) to the buildschwarze2024-11-122-29/+5
| | | | | and purge the superseded information from the algorithm-independent page EVP_PKEY_new(3).
* Document EVP_PKEY_new_CMAC_key(3) in sufficient detail such that readersschwarze2024-11-121-0/+159
| | | | | | | | | | | | | | | | | | | | | stand a chance of using the API correctly. Admittedly, having so much text below EXAMPLES is somewhat unusual. While all that information is required to use the function correctly, strictly speaking, it is not part of the specification of what EVP_PKEY_new_CMAC_key(3) does, so it woundn't really belong in the DESCRIPTION. Now, designing an API function in such a way that using it correctly requires lots of information about *other* functions and such that all that additional information does not belong into the manual pages of those other functions (both because that would cause distractions in various other manual pages and because it would scatter required information around lots of different pages) is certainly not stellar API design. But we can't help that because these APIs were all originally designed by OpenSSL. Significant feedback and OK tb@.
* Add comment for crypto_cpu_caps_aarch64.jsing2024-11-121-1/+2
|
* Use multipliers for stack offsets and tweak comment.jsing2024-11-121-9/+9
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-21 23:43:38 +0000