summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/evp (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove unused function pointer from struct aead_aes_gcm_ctx.jsing2025-07-221-2/+1
|
* Remove remaining block128_f casts from EVP AES.jsing2025-07-221-4/+4
| | | | Use aes_encrypt_block128() instead of AES_encrypt(), avoiding risky casts.
* Move AES-NI for ECB out of EVP.jsing2025-07-221-82/+1
| | | | | | | | | | Make aes_ecb_encrypt_internal() replaceable and provide machine dependent versions for amd64 and i386, which dispatch to AES-NI if appropriate. Remove the AES-NI specific EVP methods for ECB. This removes the last of the machine dependent code from EVP AES. ok bcook@ joshua@ tb@
* Move AES-NI from EVP to AES for CCM mode.jsing2025-07-211-106/+5
| | | | | | | | | | | | | | | | | The mode implementation for CCM has two variants - one takes the block function, while the other takes a "ccm64" function. The latter is expected to handle the lower 64 bits of the IV/counter but only for 16 byte blocks. The AES-NI implementation for CCM currently uses the second variant. Provide aes_ccm64_encrypt_internal() as a function that can be replaced on a machine dependent basis, along with an aes_ccm64_encrypt_generic() function that provides the default implementation and can be used as a fallback. Wire up the AES-NI version for amd64 and i386, change EVP's aes_ccm_cipher() to use CRYPTO_ctr128_{en,de}crypt_ccm64() with aes_ccm64_encrypt_internal()) and remove the various AES-NI specific EVP_CIPHER methods for CCM. ok tb@
* Simplify AES-XTS implementation and remove AES-NI specific code from EVP.jsing2025-07-131-124/+15
| | | | | | | | | Provide aes_xts_encrypt_internal() and call that from aes_xts_cipher(). Have amd64 and i386 provide their own versions that dispatch to aesni_xts_encrypt()/aesni_xts_decrypt() as appropriate. The AESNI_CAPABLE code and methods can then be removed. ok tb@
* Move aes_ecb_encrypt_internal() prototype to aes_local.h.jsing2025-07-061-4/+1
|
* Const correct EVP_PKEY_get{0,1}_{DH,DSA,EC_KEY,RSA}()tb2025-07-022-26/+22
| | | | | | | | | | | | | | | | These are safe to call concurrently and they don't modify the memory region pointed to by the pkey - they only bump the refcount of the key hanging off of it. The returned "legacy" key has to be handled with care in threaded constexts, so it is handed back as non-const. This also matches what EVP_PKEY_get0() always had. This way our signature is identical to BoringSSL's and doesn't cause compiler warnings in code that overuses const because one of the many API incoherencies added by OpenSSL 3 was to turn get0 into a function that takes and returns const while leaving get1 as it was. dlg agrees ok kenjiro
* EVP_CipherInit_ex(): normalize EVP_CIPHER_CTX_ctrl() error checktb2025-07-021-2/+2
| | | | | | | | | While EVP_CIPHER_CTX_ctrl() can return a negative value this can't actually happen currently as all ciphers with EVP_CIPH_CTRL_INIT set normalize the EVP_CTRL_INIT return value to boolean in their ctrl() methods. Still, this check looks weird in grep, so align it. ok beck kenjiro
* Simplify EVP AES-GCM implementation and remove AES-NI specific code.jsing2025-06-271-173/+25
| | | | | | | | | | | | Like CTR, the mode implementation for GCM has two variants - rather than using multiple variants (one for AES-NI, another for non-AES-NI), consistently use CRYPTO_gcm128_{en,de}crypt_ctr32() with the aes_ctr32_encrypt_internal() function added for CTR mode. This lets us remove the AES-NI specific code, AES-NI specific EVP_CIPHER methods and the ctr function pointer from EVP_AES_GCM_CTX. ok tb@
* Move AES-NI from EVP to AES for CTR mode.jsing2025-06-271-67/+1
| | | | | | | | | | | | | | | | | | | | The mode implementation for CTR has two variants - one takes the block function, while the other takes a "ctr32" function. The latter is expected to handle the lower 32 bits of the IV/counter, but is not expected to handle overflow. The AES-NI implementation for CTR currently uses the second variant. Provide aes_ctr32_encrypt_internal() as a function that can be replaced on a machine dependent basis, along with an aes_ctr32_encrypt_generic() function that provides the default implementation and can be used as a fallback. Wire up the AES-NI version for amd64 and i386, change AES_ctr128_encrypt() to use CRYPTO_ctr128_encrypt_ctr32() (which calls aes_ctr32_encrypt_internal()) and remove the various AES-NI specific EVP_CIPHER methods for CTR. Callers of AES_ctr128_encrypt() will now use AES-NI, if available. ok tb@
* Remove AES-NI specific EVP_CIPHER methods for CFB/CFB1/CFB8.jsing2025-06-161-205/+1
| | | | | | These now end up in aesni_encrypt() via AES_encrypt(), when appropriate. ok tb@
* Remove AES-NI specific EVP_CIPHER methods for OFB.jsing2025-06-161-64/+1
| | | | | | These now end up in aesni_encrypt() via AES_encrypt(), when appropriate. ok tb@
* Remove AES-NI specific EVP_CIPHER methods for CBC.jsing2025-06-161-66/+1
| | | | | | | These now end up in aesni_cbc_encrypt() via AES_cbc_encrypt(), when appropriate. ok tb@
* Remove aesni_init_key().jsing2025-06-151-47/+22
| | | | | | | | The various methods can now use the regular init key functions, since the call to AES_set_{en,de}crypt_key() will be routed to the AES-NI implementation, if supported. ok tb@
* Make OPENSSL_IA32_SSE2 the default for i386 and remove the flag.jsing2025-06-091-2/+2
| | | | | | | | | | | | | | | | | The OPENSSL_IA32_SSE2 flag controls whether a number of the perlasm scripts generate additional implementations that use SSE2 functionality. In all cases except ghash, the code checks OPENSSL_ia32cap_P for SSE2 support, before trying to run SSE2 code. For ghash it generates a CLMUL based implementation in addition to different MMX version (one MMX version hides behind OPENSSL_IA32_SSE2, the other does not), however this does not appear to actually use SSE2. We also disable AES-NI on i386 if OPENSSL_IA32_SSE2. On OpenBSD, we've always defined OPENSSL_IA32_SSE2 so this is effectively a no-op. The only change is that we now check MMX rather than SSE2 for the ghash MMX implementation. ok bcook@ beck@
* Fix EVP_DecryptFinal() for CCM cipherstb2025-06-061-5/+10
| | | | | | | | | | | | | There is an old trap that you must not call EVP_*Final() when using AES-CCM. While encrypting this happens to be a noop and succeeds, but when decrypting, the call fails. This behavior changed in OpenSSL and BoringSSL, making the trap even worse since we now fail when the others succeed. This is an adaptation of OpenSSL commit 197421b1 to fix this. See also https://github.com/sfackler/rust-openssl/pull/1805#issuecomment-2734788336 ok beck kenjiro
* Use timingsafe_memcmp when comparing authenticatorskenjiro2025-06-031-3/+3
| | | | | | | | | | | Replace memcmp() with timingsafe_memcmp() for authentication tag comparison in AES-CCM, GCM, PKCS12 and AES key unwrap code paths to ensure constant-time behavior and avoid potential timing side channels. This aligns with OpenSSL 1e4a355. ok tb@
* Inline EVP_CIPHER_[gs]et_asn1_iv() in their last callerstb2025-06-021-27/+15
| | | | ok kenjiro
* Make EVP_CIPHER_[gs]et_asn1_iv() local to evp_ciphertb2025-05-279-153/+174
| | | | | | | | | | | | | These formerly public functions have only ever been called from EVP_CIPHER_asn1_to_param() and EVP_CPIHER_param_to_asn1(), either directly if the EVP_CIPH_FLAG_DEFAULT_ASN1 flag is set, or indirectly when set as the .[gs]et_asn1_parameters() method of the EVP_CIPHER. This commit removes their use in .[gs]et_asn1_parameters() dating back to long before the EVP_CIPH_FLAG_DEFAULT_ASN1 was introduced in 2010. This way the only remaining consumer of .[gs]et_asn1_parameters() is RC2. ok jsing
* GOST has left the buildingtb2025-05-261-2/+2
| | | | (comment tweak, no code change)
* Simplify EVP AES code for ECB.jsing2025-05-191-32/+33
| | | | | | | | | | AES_ecb_encrypt() does not really do ECB - provide an aes_ecb_encrypt_internal that actually does multiple blocks and call this from aes_ecb_cipher(). Provide ECB with its own key initialisation function, which allows aes_init_key() to be simplified considerably. The block function pointer is now unused, so mop this up. ok joshua@ tb@
* Simplify EVP AES code for OFB.jsing2025-05-191-7/+19
| | | | | | | Provide AES-NI with its own aesni_ofb_cipher() and switch aes_ofb_cipher() to call AES_ofb128_encrypt() directly. ok joshua@ tb@
* Simplify EVP AES code for CFB.jsing2025-05-191-25/+79
| | | | | | | | Provide AES-NI with its own aesni_cfb*_cipher() functions, which then allows us to change the existing aes_cfb*_cipher() functions to () to call AES_cfb*_encrypt() directly. ok beck@ tb@
* Simplify EVP AES code for CTR.jsing2025-05-181-22/+23
| | | | | | | | Provide AES-NI with its own aesni_ctr_cipher(), which then allows us to change aes_ctr_cipher() to call AES_ctr128_encrypt() directly. The stream.ctr function pointer is now unused and can be mopped up. ok beck@ tb@
* Unifdef AES_CTR_ASM.jsing2025-05-181-14/+1
| | | | This is a remnant from s390x assembly.
* Simplify EVP code for AES CBC.jsing2025-05-181-26/+33
| | | | | | | | | Change aes_cbc_cipher() to call AES_cbc_encrypt() directly, rather than via the stream.cbc function pointer. Remove stream.cbc since it is no longer used. Also provide a separate aes_cbc_init_key() function which makes this standalone and does not require checking mode flags. ok joshua@ tb@
* Use err_local.h rather than err.h in most placestb2025-05-1019-38/+35
| | | | ok jsing
* Fix indentation and line wrapping.jsing2025-04-181-17/+15
|
* Remove BS-AES and VP-AES from EVP.jsing2025-04-181-129/+7
| | | | | | | | | | | | | | | | | The bitsliced and vector permutation AES implementations were created around 2009, in attempts to speed up AES on Intel hardware. Both require SSSE3 which existed from around 2006. Intel introduced AES-NI in 2008 and a large percentage of Intel/AMD CPUs made in the last 15 years include it. AES-NI is significantly faster and requires less code. Furthermore, the BS-AES and VP-AES implementations are wired directly into EVP (as is AES-NI currently), which means that any consumers of the AES_* API are not able to benefit from acceleration. Removing these greatly simplifies the EVP AES code - if you just happen to have a CPU that supports SSSE3 but not AES-NI, then you'll now use the regular AES assembly implementations instead. ok kettenis@ tb@
* Error check i2t_ASN1_OBJECT() and tweak warning messagetb2025-02-041-2/+4
| | | | | | CID 532326 ok djm jsing
* Annotate why EVP_PKEY_CTX_ctrl_str() will stay for a whiletb2025-01-201-1/+6
|
* If EVP_CIPHER_CTX_ctrl(3) is called on EVP_chacha20_poly1305(3)schwarze2024-12-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | with an unsupported control command, return -1 rather than 0 to the caller to indicate the error because in general, these control hooks ought to return -1 for unsupported control commands and 0 for other errors, for example other invalid arguments. Not a big deal because this change does not change when operations succeed or fail, and because callers are unlikely to pass unsupported control commands in the first place. The only functional change is that if a calling program inspects the ERR(3) stack after this failure, it will now find the correct error code rather than nothing. Even that wasn't a huge problem because for most EVP_CIPHER control failures, getting no reason for the error is the usual situation. Then again, giving the reason when easily possible may occasionally be useful. OpenSSL also returns -1 in this case, so it also helps compatibility a tiny bit. Found while auditing the return values of all the EVP_CIPHER control hooks in our tree. This was the only fishy one i found. OK tb@
* Reenable AES-NI in libcryptotb2024-09-061-3/+5
| | | | | | | | | | | | | | | | | | | The OPENSSL_cpu_caps() change after the last bump missed a crucial bit: there is more MD mess in the MI code than anticipated, with the result that AES is now used without AES-NI on amd64 and i386, hurting machines that previously greatly benefitted from it. Temporarily add an internal crypto_cpu_caps_ia32() API that returns the OPENSSL_ia32cap_P or 0 like OPENSSL_cpu_caps() previously did. This can be improved after the release. Regression reported and fix tested by Mark Patruck. No impact on public ABI or API. with/ok jsing PS: Next time my pkg_add feels very slow, I should perhaps not mechanically blame IEEE 802.11...
* Nuke the whrlpool (named after the galaxy) from orbittb2024-08-313-64/+2
| | | | | | | It's just gross. Only used by a popular disk encryption utility on an all-too-popular OS one or two decades back. ok beck jsing
* Remove EVP_PKEY.*attr* APItb2024-08-311-81/+1
| | | | | | I ranted enough about this recently. PKCS#12. Microsoft. 'nuff said. ok beck jsing
* Remove EVP_PKEY_*check againtb2024-08-312-33/+2
| | | | | | | | | | | | | | | This API turned out to be a really bad idea. OpenSSL 3 extended it, with the result that basically every key type had its own DoS issues fixed in a recent security release. We eschewed these by having some upper bounds that kick in when keys get insanely large. Initially added on tobhe's request who fortunately never used it in iked, this was picked up only by ruby/openssl (one of the rare projects doing proper configure checks rather than branching on VERSION defines) and of course xca, since it uses everything it can. So it was easy to get rid of this again. ok beck jsing
* Remove the pkey_{,public_,param_}check() handlerstb2024-08-292-58/+12
| | | | | | | | This disables the EVP_PKEY_*check() API and makes it fail (more precisely indicate lack of support) on all key types. This is an intermediate step to full removal. Removal is ok beck jsing
* Implement X509_get_signature_info()tb2024-08-281-1/+4
| | | | | | | | | | | | | | | | This is a slightly strange combination of OBJ_find_sigid_algs() and the security level API necessary because OBJ_find_sigid_algs() on its own isn't smart enough for the special needs of RSA-PSS and EdDSA. The API extracts the hash's NID and the pubkey's NID from the certificate's signatureAlgorithm and invokes special handlers for RSA-PSS and EdDSA for retrieving the corresponding information. This isn't entirely free for RSA-PSS, but for now we don't cache this information. The security bits calculation is a bit hand-wavy, but that's something that comes along with this sort of numerology. ok jsing
* Garbage collect unused attributes member from EVP_PKEYtb2024-08-222-4/+2
| | | | ok miod
* Neuter EVP_PKEY_add1_attr_by_NID()tb2024-08-221-36/+5
| | | | | | | The last consumer in openssl(1) pkcs12 has been removed, so we no longer need this function. ok miod
* typo: regresss -> regresstb2024-07-291-2/+2
|
* Rewrite EVP_PKEY_add1_attr_by_NID()tb2024-07-141-11/+41
| | | | | | | Instead of jumping through many layers that cause headache, we can achieve the same in an entirely straightforward way without losing clarity. ok jsing
* Disable most EVP_PKEY_*attr* APItb2024-07-141-14/+17
| | | | | | | | There is a single consumer of this entire family of function, namely the openssl(1) pkcs12 command uses EVP_PKEY_add1_attr_by_NID, so leave that one intact for now. ok jsing
* Add tls1_prf_pkey_meth to pkey_methodstb2024-07-091-1/+3
| | | | ok jsing
* Add EVP_PKEY_TLS1_PRF as alias for NID_tls1_prftb2024-07-091-1/+2
| | | | ok jsing
* libcrypto: constify most error string tablestb2024-06-241-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | These constitute the bulk of the remaining global mutable state in libcrypto. This commit moves most of them into data.rel.ro, leaving out ERR_str_{functs,libraries,reasons} (which require a slightly different approach) and SYS_str_reasons which is populated on startup. The main observation is that if ERR_load_strings() is called with a 0 lib argument, the ERR_STRING_DATA argument is not actually modified. We could use this fact to cast away const on the caller side and be done with it. We can make this cleaner by adding a helper ERR_load_const_strings() which explicitly avoids the assignment to str->error overriding the error code already set in the table. In order for this to work, we need to sprinkle some const in err/err.c. CMS called ERR_load_strings() with non-0 lib argument, but this didn't actually modify the error data since it ored in the value already stored in the table. Annoyingly, we need to cast const away once, namely in the call to lh_insert() in int_err_set_item(). Fixing this would require changing the public API and is going to be tricky since it requires that the LHASH_DOALL_FN_* types adjust. ok jsing
* Fix in-place decryption for EVP_chacha20_poly1305()tb2024-05-221-3/+3
| | | | | | | | | | | | | Take the MAC before clobbering the input value on decryption. Fixes hangs during the QUIC handshake with HAProxy using TLS_CHACHA20_POLY1305_SHA256. Found, issue pinpointed, and initial fix tested by Lucas Gabriel Vuotto: Let me take this opportunity to thank the HAProxy team for going out of their way to keep supporting LibreSSL. It's much appreciated. See https://github.com/haproxy/haproxy/issues/2569 tweak/ok jsing
* Avoid NULL dereference in EVP_PKEY_paramgen()tb2024-04-171-6/+8
| | | | | | | | If EVP_PKEY_new() returns NULL, it would be passed to the paramgen() pmeth which would typically dereference it. This is identical to a recent change in keygen(). ok jsing
* Delete a few more GOST remnantstb2024-04-141-21/+1
| | | | | | | | When I unifdefed GOST support, the tree wasn't fully unlocked, so I didn't want to touch a public header. All this code is in #ifndef OPENSSL_NO_GOST, which we define. ok jsing
* bio_enc: various basic cleanuptb2024-04-121-64/+67
| | | | | | | | Call a BIO bio rather than bi, a, or b; don't cast when assigning from or to a (void *). Drop loads of silly redundant parentheses, use better order of variable declarations. No change in the generated assembly
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-24 14:12:06 +0000