A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9 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-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@ 2025-06-16T14:50:30+00:00 jsing 2025-06-16T14:50:30+00:00 urn:sha1:bad753f7a00446ace848a9b450c42d5a798d8e13 These now end up in aesni_encrypt() via AES_encrypt(), when appropriate. ok tb@ 2025-06-16T14:42:18+00:00 jsing 2025-06-16T14:42:18+00:00 urn:sha1:84d57f4f5b4c9b0bc1cff54f7194b002bd0af5e8 These now end up in aesni_encrypt() via AES_encrypt(), when appropriate. ok tb@