A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_8_BASE 2025-09-08T12:56:17+00:00 2025-09-08T12:56:17+00:00 jsing 2025-09-08T12:56:17+00:00 urn:sha1:edb41402990165c33fbbe4972a505d2b907f57b5 Rename the C based AES implementation to *_generic() and provide *_internal() wrappers for these. This allows for architectures to provide accelerated versions without having to also provide a fallback implementation. ok tb@ 2025-08-14T15:11:01+00:00 jsing 2025-08-14T15:11:01+00:00 urn:sha1:d31d4089b9ae677123f49cc1b071b80207baf184 Add detection of Multi-Precision Add-Carry Instruction Extensions on amd64. s2n-bignum provides a number of fast multiplication routines that can leverage these instructions. ok tb@ 2025-07-22T09:18:02+00:00 jsing 2025-07-22T09:18:02+00:00 urn:sha1:cbc4928ebdbd9c244a1c0e3c2e90497a0d246b38 There are no more consumers of crypto_cpu_caps_ia32(), so remove it. ok bcook@ joshua@ tb@ 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-06-28T12:39:10+00:00 jsing 2025-06-28T12:39:10+00:00 urn:sha1:48723f4db60f6f8a8ad8424ffe5e0262d30f397c Provide gcm128_amd64.c and gcm128_i386.c, which contain the appropriate gcm128 initialisation and CPU feature tests for the respective platform. This allows for all of the #define spagetti to be removed from gcm128.c and removes one of the two remaining consumers of crypto_cpu_caps_ia32(). ok tb@ 2025-06-28T12:20:39+00:00 jsing 2025-06-28T12:20:39+00:00 urn:sha1:c534647b2ec7521ee4210dd398faaad0018287d0 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-15T14:16:11+00:00 jsing 2025-06-15T14:16:11+00:00 urn:sha1:00556dbdb2a0ef259141c777042dfb7562f0b7c5 ok tb@