A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v4.2.1 2025-07-22T09:31:09+00:00 2025-07-22T09:31:09+00:00 jsing 2025-07-22T09:31:09+00:00 urn:sha1:ccfa2eb65bcf08f9a43232aa86ef9db63b417902 2025-07-22T09:29:31+00:00 jsing 2025-07-22T09:29:31+00:00 urn:sha1:bac3e025d0e76adcdafc8b26a67bf5a0a4abbed6 Use aes_encrypt_block128() instead of AES_encrypt(), avoiding risky casts. 2025-07-22T09:13:49+00:00 jsing 2025-07-22T09:13:49+00:00 urn:sha1:da7a63b669ad2a502ae120afede3fd850082e8b6 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@ 2025-07-21T10:24:23+00:00 jsing 2025-07-21T10:24:23+00:00 urn:sha1:b73facdeca098be7e538e556c1a293942db3110c 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@ 2025-07-13T06:01:33+00:00 jsing 2025-07-13T06:01:33+00:00 urn:sha1:f0234f5a33ecf3b2784f3e73bdf1e937abe56599 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@ 2025-07-06T15:37:33+00:00 jsing 2025-07-06T15:37:33+00:00 urn:sha1:1e1239f964a6fb20dc61c74aa0a96f5cca517235 2025-07-02T06:36:52+00:00 tb 2025-07-02T06:36:52+00:00 urn:sha1:ee8028bd119b3e4cd917dc91bde28658b6256b9f 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 2025-07-02T06:19:46+00:00 tb 2025-07-02T06:19:46+00:00 urn:sha1:ad601ff02961740f5ae318c6636c0f79f9d72ae4 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 2025-06-27T17:26:57+00:00 jsing 2025-06-27T17:26:57+00:00 urn:sha1:fd19eff2f98d72aee359ddccbf890bac0361fb66 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@ 2025-06-27T17:10:45+00:00 jsing 2025-06-27T17:10:45+00:00 urn:sha1:abb03e21a8d0fc7f97a871f5aee5a8084176540f 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@