openbsd/src/lib/libcrypto/aes, branch libressl-v4.2.1A mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=libressl-v4.2.12025-09-15T07:36:12+00:00aes: move explicit_bzero() after NULL check2025-09-15T07:36:12+00:00tb2025-09-15T07:36:12+00:00urn:sha1:1f8d0b443d28c5e431333f56e1a6384d8123e15c
CID 621601 621602
ok djm jsg jsing miod
Call aes_set_encrypt_key_generic() from aes_set_decrypt_key_generic().2025-09-08T13:37:39+00:00jsing2025-09-08T13:37:39+00:00urn:sha1:acdada09380aa5022157b7b571ff54855ef99792
With the renaming, aes_set_decrypt_key_generic() should now call
aes_set_encrypt_key_generic() directly.
Allow generic AES implementation to be used as a fallback.2025-09-08T12:56:17+00:00jsing2025-09-08T12:56:17+00:00urn: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@
Zero the round keys on AES_set_{en,de}crypt_key() function entry.2025-09-08T12:50:02+00:00jsing2025-09-08T12:50:02+00:00urn:sha1:0b23e36dfa750e5a98824fc469f69a27c5f25d3b
This avoids leaving previous round keys around on failure, or leaving parts
of previous round keys behind if reused with a smaller key size.
ok tb@
Validate AES_set_{encrypt,decrypt}_key() inputs at API boundary.2025-09-08T12:46:38+00:00jsing2025-09-08T12:46:38+00:00urn:sha1:27935bc83495bf29902f88b49a448b5fba6cb8ac
Every aes_set_{encrypt,decrypt}_key_internal() implementation is currently
required to check the inputs and return appropriate error codes. Pull the
input validation up to the API boundary, setting key->rounds at the same
time. Additionally, call aes_set_encrypt_key_internal() directly from
aes_set_decrypt_key_internal(), rather than going back through the public
API.
ok tb@
Remove remaining block128_f casts from EVP AES.2025-07-22T09:29:31+00:00jsing2025-07-22T09:29:31+00:00urn:sha1:bac3e025d0e76adcdafc8b26a67bf5a0a4abbed6
Use aes_encrypt_block128() instead of AES_encrypt(), avoiding risky casts.
Move AES-NI for ECB out of EVP.2025-07-22T09:13:49+00:00jsing2025-07-22T09:13:49+00:00urn: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@
Move AES-NI from EVP to AES for CCM mode.2025-07-21T10:24:23+00:00jsing2025-07-21T10:24:23+00:00urn: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@
Zero stack based IV and buffer when aes_ctr32_encrypt_generic() completes.2025-07-20T08:55:49+00:00jsing2025-07-20T08:55:49+00:00urn:sha1:32c75086555dc2a71cc1500a21b0d024fe48ceaf
ok tb@
Simplify AES-XTS implementation and remove AES-NI specific code from EVP.2025-07-13T06:01:33+00:00jsing2025-07-13T06:01:33+00:00urn: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@