summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
|
* Check the correct variable in cpuid().jsing2024-11-122-4/+4
|
* 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-123-273/+206
|
* KNF nit for end of comment markertb2024-11-121-2/+2
|
* Rename ecp_smpl.c to ecp_methods.ctb2024-11-122-3/+3
| | | | | | | | 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
* Fix a brainfart that happened to me in 2020:schwarze2024-11-121-9/+7
| | | | | | | | | | It is impossible to use EVP_DigestInit_ex(3) for CMAC. Besides, EVP_PKEY_CTX_new_id(3) does not produce an EVP_MD_CTX object. Instead, mention the easiest way to actually get the job done using EVP_PKEY_new_CMAC_key(3) and EVP_DigestSignInit(3). OK tb@
* Wrap comment badly mistreated by an autoformatter due to missing /*-tb2024-11-101-3/+6
|
* Garbage collect an unused variabletb2024-11-101-3/+1
|
* Mention the key lengths of some encryption algorithms.schwarze2024-11-094-21/+47
| | | | | | | | This is relevant because EVP_EncryptInit(3) takes a "key" argument, and users need to consider the size of that argument. While here, also mention whether ciphers are stream ciphers or block ciphers and what the block size is.
* Weed out the last remaining refences to the obsoleteschwarze2024-11-084-67/+77
| | | | | | | | function EVP_MD_CTX_init(3) and talk about EVP_MD_CTX_new(3) instead. This is similar in spirit to OpenSSL commit 25191fff (Dec 1, 2015), but i'm also mentioning EVP_MD_CTX_reset(3), slightly reordering some sentences in a more systematic way, and improving some related wordings to be more precise and read better.
* 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-03-22 02:48:20 +0000