summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/aes (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove remaining block128_f casts from EVP AES.jsing2025-07-221-1/+4
| | | | Use aes_encrypt_block128() instead of AES_encrypt(), avoiding risky casts.
* Move AES-NI for ECB out of EVP.jsing2025-07-223-3/+53
| | | | | | | | | | 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-214-4/+136
| | | | | | | | | | | | | | | | | 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.jsing2025-07-201-1/+4
| | | | ok tb@
* Simplify AES-XTS implementation and remove AES-NI specific code from EVP.jsing2025-07-134-4/+96
| | | | | | | | | 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-1/+4
|
* Simplify EVP AES-GCM implementation and remove AES-NI specific code.jsing2025-06-271-1/+4
| | | | | | | | | | | | 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-273-5/+88
| | | | | | | | | | | | | | | | | | | | 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 unused defines from aes_local.h.jsing2025-06-271-5/+1
| | | | | | | | | MAXKB was added in OpenSSL commit deb2c1a1 and appears to have never been used, while MAXKC (originally RIJNDAEL_MAXKC) stopped being used in that same commit. MAXNR is also unused - AES_MAXNR exists in the public header. ok tb@
* Integrate AES-NI into the AES code.jsing2025-06-154-60/+264
| | | | | | | | | | Currently, the AES-NI code is only integrated into EVP - add code to integrate AES-NI into AES. Rename the assembly provided functions and provide C versions for the original names, which check for AES-NI support and dispatch to the appropriate function. This means that the AES_* public API will now use AES-NI, if available. ok tb@
* Use timingsafe_memcmp when comparing authenticatorskenjiro2025-06-031-2/+2
| | | | | | | | | | | 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@
* Merge AES-IGE into aes.c.jsing2025-05-252-119/+65
|
* Simplify AES-IGE and remove code with implementation defined behaviour.jsing2025-05-251-117/+40
| | | | | | | | | Remove the UNALIGNED_MEMOPS_ARE_FAST from AES-IGE, which can result in implementation defined behaviour on i386/amd64. While we could keep this purely for aligned inputs and outputs, it's probably not that important and can be redone in a simpler form later if we want to do so. ok tb@
* Remove now unused AES assembly generation scripts.jsing2025-05-213-5256/+0
|
* Simplify EVP AES code for ECB.jsing2025-05-191-1/+13
| | | | | | | | | | 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@
* Remove block128_f function casts.jsing2025-05-191-8/+20
| | | | | | | Provide aes_{en,de}crypt_block128() which have correct function signatures and use these when calling the various mode functions. ok joshua@ tb@
* Use standard integer types rather than custom typedefs.jsing2025-04-212-25/+21
| | | | | | Replace u32 with uint32_t, remove unused u16 and replace u8 with uint8_t. ok tb@
* Move AES public functions from aes_core.c to aes.c.jsing2025-04-202-56/+47
| | | | | | This is where almost all of the public functions exist. ok beck@ tb@
* Remove #error if OPENSSL_NO_FOO is definedtb2025-01-252-10/+2
| | | | discussed with jsing
* AES_{decrypt,encrypt}() don't return void internal functiontb2024-11-131-3/+3
| | | | | | | "A return statement with an expression shall not appear in a function whose return type is void." ok deraadt miod
* Provide and use crypto_arch.h.jsing2024-08-112-2/+5
| | | | | | | | Provide a per architecture crypto_arch.h - this will be used in a similar manner to bn_arch.h and will allow for architecture specific #defines and static inline functions. Move the HAVE_AES_* and HAVE_RC4_* defines here. ok tb@
* Hide symbols in aesjoshua2024-03-303-3/+17
| | | | ok jsing
* Tweak defines since the Td4 table is only used for AES_{encrypt,decrypt}jsing2024-03-291-6/+9
|
* Always use C functions for AES_{encrypt,decrypt}().jsing2024-03-298-79/+107
| | | | | | | Always provide AES_{encrypt,decrypt}() via C functions, which then either use a C implementation or call the assembly implementation. ok tb@
* Always use C functions for AES_set_{encrypt,decrypt}_key().jsing2024-03-295-54/+85
| | | | | | | | Always include aes_core.c and provide AES_set_{encrypt,decrypt}_key() via C functions, which then either use a C implementation or call the assembly implementation. ok tb@
* Rename AES_cbc_encrypt to aes_cbc_encrypt_internal for the SEH handlers.jsing2024-03-291-4/+4
| | | | Should fix windows build.
* Merge aes_cbc.c into aes.c now that aes_cbc.c is used on all platforms.jsing2024-03-282-79/+26
|
* Make AES_cbc_encrypt() always be a C function.jsing2024-03-283-15/+26
| | | | | | | | Rename the assembly generated functions from AES_cbc_encrypt() to aes_cbc_encrypt_internal(). Always include aes_cbc.c and change it to use defines that are similar to those used in BN. ok tb@
* Consolidate most of the AES modes into a single C file.jsing2024-03-285-287/+68
| | | | Discussed with tb@
* Remove assembly for stitched modes.jsing2024-03-271-1237/+0
| | | | | The stitched modes have been removed, so having assembly for them is of little use.
* Replace GETU32 and PUTU32.jsing2024-03-272-29/+26
| | | | | | | | Replace GETU32 with crypto_load_be32toh() and PUTU32 with crypto_store_htobe32(). Make the offset handling cleaner at the same time. ok beck@ joshua@ tb@
* Remove near duplicate AES_set_{encrypt,decrypt}_key() functions.jsing2024-03-271-208/+2
| | | | | | | | | | | | | | | There are currently three ways in which AES is implemented - all in assembly (amd64 et al), all in C (aarch64 et al) and, half in C and half in assembly (hppa and sparc64). The last of these cases currently makes use of a near duplicate AES_set_{encrypt,decrypt}_key() implementation that avoids using the AES tables. Remove the near duplicate version and if only a half assembly version is implemented, use the same C version of AES_set_{encrypt,decrypt}_key() as everyone else. This adds around 8KB of rodata to libcrypto on these two platforms. Discussed with beck and tb.
* Use crypto_rol_u32() instead of an undefined ROTATE macro.jsing2024-03-271-9/+5
| | | | ok tb@
* Remove unused NDEBUG define.jsing2024-03-271-7/+1
|
* Tidy includes and a comment.jsing2024-03-271-3/+7
|
* Remove rather scary unused experimental code.jsing2024-03-271-1081/+0
| | | | ok tb@
* Add a few missing endbr64 to libcryptotb2024-02-241-0/+4
| | | | | | | | gcm_{gmult,ghash}_4bit(), aesni_ccm64_decrypt_blocks(), aes_cbc_encrypt(), and aesni_xts_{en,de}crypt() were overlooked in previous passes. Found with a diff for ld.lld by kettenis ok kettenis
* Replace uses of endbr64 with _CET_ENDBR from cet.htb2024-02-245-61/+61
| | | | | | | | | cet.h is needed for other platforms to emit the relevant .gnu.properties sections that are necessary for them to enable IBT. It also avoids issues with older toolchains on macOS that explode on encountering endbr64. based on a diff by kettenis ok beck kettenis
* aesni_ctr32_encrypt_blocks() is called indirectly from C code, so itderaadt2023-09-181-0/+1
| | | | | needs endbr64 ok kettenis tb
* Remove more *_options() stufftb2023-07-311-3/+1
| | | | | | | The public symbols were removed. Some prototypes and in the case of DES even the implementation remained. ok jsing
* Two files did not want to go away. Go!tb2023-07-281-0/+0
|
* Remove various ${thing}_optionstb2023-07-281-65/+0
| | | | | | | | | | Various, ancient ciphers exposed some of their innards via an _options() API. Apart from openssl version/speed, only some lua thingie in nmap ever looked at these. Go figure. hppa testing by miod, i386 testing by sthen. Thanks! ok jsing
* Add endbr64 where needed by inspection. Passes regresson tests.deraadt2023-04-255-0/+60
| | | | ok jsing, and kind of tb an earlier version
* Drop two useless READMEstb2023-04-171-3/+0
| | | | "go ahead" jsing
* Use explicit .text instead of .previous to please Windows/MinGW on amd64tb2023-02-235-5/+5
| | | | ok miod
* Use .section .rodata instead of a plain .rodatatb2023-02-095-5/+5
| | | | | | | | At least gcc 12 on Fedora is very unhappy about a plain .rodata and throws Error: unknown pseudo-op: `.rodata'. So add a .section in front of it to make it happy. ok deraadt miod
* Remove AIX toc data after every function. NFCmiod2023-02-021-23/+2
|
* Unbreak vpaes-x86 implementation.jsing2023-02-021-2/+0
| | | | | | Remove remnants of previous PIC handling. ok miod@
* Move all data blocks from .text to .rodata and cleanup up and homogeneize codemiod2023-02-013-38/+42
| | | | | | responsible from getting the proper address of those blocks. ok tb@ jsing@
* Move constants out of text segment into rodata to prepare for xonly supportderaadt2023-01-145-7/+10
| | | | | on amd64. no pic handling is neccessary since amd64 has full reach. ok kettenis
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-23 19:16:45 +0000