summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/modes (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Simplify AES-XTS implementation and remove AES-NI specific code from EVP.jsing2025-07-131-2/+2
| | | | | | | | | 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@
* Rework gcm128 implementation selection for amd64/i386.jsing2025-06-283-57/+113
| | | | | | | | | 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@
* Use a single implementation of gcm_mul()/gcm_ghash().jsing2025-06-281-19/+8
| | | | | | | | Since we always initialise the gmult/ghash function pointers, use the same implementaion of gcm_mul() and gcm_ghash(), regardless of the actual underlying implementation. ok tb@
* Remove less than useful comment.jsing2025-06-281-8/+1
|
* Make OPENSSL_IA32_SSE2 the default for i386 and remove the flag.jsing2025-06-092-9/+2
| | | | | | | | | | | | | | | | | The OPENSSL_IA32_SSE2 flag controls whether a number of the perlasm scripts generate additional implementations that use SSE2 functionality. In all cases except ghash, the code checks OPENSSL_ia32cap_P for SSE2 support, before trying to run SSE2 code. For ghash it generates a CLMUL based implementation in addition to different MMX version (one MMX version hides behind OPENSSL_IA32_SSE2, the other does not), however this does not appear to actually use SSE2. We also disable AES-NI on i386 if OPENSSL_IA32_SSE2. On OpenBSD, we've always defined OPENSSL_IA32_SSE2 so this is effectively a no-op. The only change is that we now check MMX rather than SSE2 for the ghash MMX implementation. ok bcook@ beck@
* More code clean up.jsing2025-06-081-10/+9
| | | | | Fix some things that got missed in the last pass - the majority is use of post-increment rather than unnecessary pre-increment.
* Remove more mess related to arm assembly.jsing2025-06-081-23/+1
|
* Mop up ghash arm assembly remnants.jsing2025-05-241-18/+1
|
* Do a clean up pass over the GCM code.jsing2025-05-221-92/+86
| | | | | | | | Rework some logic, add explicit numerical checks, move assignment out of variable declaration and use post-increment/post-decrement unless there is a specific reason to do pre-increment. ok kenjiro@ tb@
* Use timingsafe_memcmp() in CRYPTO_gcm128_finish().jsing2025-05-221-2/+2
| | | | | | When checking the GCM tag, use timingsafe_memcmp() instead of memcmp(). ok tb@
* Reorder some functions.jsing2025-05-211-20/+20
|
* Remove GHASH_CHUNK and size_t related code from GCM encrypt/decrypt.jsing2025-05-211-220/+1
| | | | | | | | This adds significant complexity to the code. On amd64 and aarch64 it results in a minimal slowdown for aligned inputs and a performance improvement for unaligned inputs. ok beck@ joshua@ tb@
* Fix wrapping.jsing2025-05-211-13/+9
|
* Remove more unused code.jsing2025-05-211-95/+1
| | | | Discussed with tb@
* Unbreak GHASH on some architectures setting GHASH_ASMtb2025-05-201-1/+3
| | | | | | | | The last #else branch in CRYPTO_gcm128_init() doesn't initialize the function pointers for gmult/ghash, which results in a segfault when using GCM on architectures taking this branch, notably sparc64. found by and fix from jca
* add missing u64/uint64_t conversionbcook2025-05-181-3/+3
| | | | ok jsing@
* Use stdint types instead of u64/u32/u8.jsing2025-05-185-134/+127
| | | | No change in generated assembly.
* Remove contortions with the rem_4bit table.jsing2025-05-181-28/+9
| | | | | | | | | Instead of using size_t and a PACK macro, store the entries as uint16_t and then uncondtionally left shift 48 bits. This gives a small performance gain on some architectures and has the advantage of reducing the size of the table from 1024 bits to 256 bits. ok beck@ joshua@ tb@
* Inline REDUCE1BIT macro.jsing2025-05-181-15/+6
| | | | | | | | | The REDUCE1BIT macro is now only used in one place, so just inline it. Additionally we do not need separate 32 bit and 64 bit versions - just use the 64 bit version and let the compiler deal with it (we effectively get the same code on i386). ok beck@ joshua@
* Remove TABLE_BITS from gcm128.jsing2025-05-172-248/+3
| | | | | | | | | TABLE_BITS is always currently defined as 4 - 8 is considered to be insecure due to timing leaks and 1 is considerably slower. Remove code that is not regularly tested, does not serve a lot of purpose and is making clean up harder than it needs to be. ok tb@
* Replace GCM_MUL/GHASH defines with static inline functions.jsing2025-05-161-121/+99
| | | | | | | | | Rather than having defines for GCM_MUL/GHASH (along with the wonder that is GCM_FUNCREF_4BIT) then conditioning on their availability, provide and call gcm_mul()/gcm_ghash() unconditionally. This simplifies all of the call sites. ok tb@
* Restore two #if defined(GHASH) that were incorrectly removed.jsing2025-04-251-5/+5
| | | | | | | Also condition on defined(GHASH_CHUNK) since this is used within these blocks. This makes the conditionals consistent with other usage. Fixes build with TABLE_BITS == 1.
* Unifdef OPENSSL_SMALL_FOOTPRINT.jsing2025-04-251-13/+5
| | | | ok tb@
* Use the OPENSSL_SMALL_FOOTPRINT code in gcm_init_4bit().jsing2025-04-251-32/+2
| | | | | | | | A modern compiler will unroll these loops - LLVM produces identical code (at least on arm64). Drop the manually unrolled version and have code that is more readable and maintainable. ok tb@
* Mop up all of the GETU32/BSWAP4/BSWAP8 macros since they're now unused.jsing2025-04-232-44/+2
| | | | ok beck@ tb@
* Rewrite gcm_gmult_1bit() to avoid sizeof(long) hacks.jsing2025-04-231-22/+8
| | | | | | | | | | | We're already using 64 bit variables, so just continue to do so and let the compiler deal with code generation. While here, use unsigned right shifts instead of relying on signed right shifts and implementation-defined behaviour (which the original code did). Feedback from lucas@ ok beck@ tb@
* Fix CRYPTO_gcm128_decrypt() when compiled with TABLE_BITS == 1.jsing2025-04-231-3/+3
| | | | | | | | | This appears to have been broken since 2013 when OpenSSL commit 3b4be0018b5 landed. This added in_t and out_t variables, but continued to use in and out instead. Yet another reason why untested conditional code is a bad thing. ok beck@ tb@
* Unifdef OPENSSL_SMALL_FOOTPRINT.jsing2025-04-234-18/+4
| | | | | | | We do not build with OPENSSL_SMALL_FOOTPRINT and it removes more untested code paths. Request by tb@ (and it was already on my TODO list!)
* Mop up OPENSSL_FIPSAPI define.jsing2025-04-221-3/+1
|
* Use OPENSSL_assert() instead of assert().jsing2025-04-221-10/+6
| | | | | | While here, tidy up the assignment of n and test directly. ok tb@
* Remove now unused PUTU32 macros from modes_local.h.jsing2025-04-221-3/+1
| | | | ok tb@
* Use crypto_load_be32toh()/crypto_store_htobe32() instead of GETU32/PUTU32.jsing2025-04-221-4/+6
| | | | ok tb@
* Mop up unused MODES_DEBUG.jsing2025-04-217-49/+7
|
* Fix another #include that was hiding.jsing2025-04-211-2/+2
|
* Tidy includes.jsing2025-04-216-14/+25
|
* Reenable AES-NI in libcryptotb2024-09-061-5/+8
| | | | | | | | | | | | | | | | | | | The OPENSSL_cpu_caps() change after the last bump missed a crucial bit: there is more MD mess in the MI code than anticipated, with the result that AES is now used without AES-NI on amd64 and i386, hurting machines that previously greatly benefitted from it. Temporarily add an internal crypto_cpu_caps_ia32() API that returns the OPENSSL_ia32cap_P or 0 like OPENSSL_cpu_caps() previously did. This can be improved after the release. Regression reported and fix tested by Mark Patruck. No impact on public ABI or API. with/ok jsing PS: Next time my pkg_add feels very slow, I should perhaps not mechanically blame IEEE 802.11...
* Add a few missing endbr64 to libcryptotb2024-02-241-0/+2
| | | | | | | | 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-241-4/+4
| | | | | | | | | 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
* Avoid a four-byte overread in gcm_ghash_4bit_mmx() on i386tb2024-01-241-1/+1
| | | | | | | This is a variant of the same logic error fixed in ghash-x86_64.pl r1.6. The code path is only reachable on machines without FXSR or PCLMUL. ok jsing
* Avoid a four byte overread in gcm_ghash_4bit() on amd64.jsing2024-01-241-1/+1
| | | | | | | | | | | | | | The assembly code for gcm_ghash_4bit() reads one too many times from Xi, resulting in a four byte overread. Prevent this by not loading the next value in the final iteration of the loop. If another full iteration is required the next Xi value will be loaded at the top of the outer_loop. Many thanks to Douglas Gliner <Douglas.Gliner at sony dot com> for finding and reporting this issue, along with a detailed reproducer. Same diff from deraadt@ ok tb@
* Improve byte order handling in gcm128.jsing2023-08-101-329/+44
| | | | | | Replace a pile of byte order handling mess with htobe*() and be*toh(). ok tb@
* Hide symbols in modes.hbeck2023-07-087-7/+35
| | | | ok tb@
* Hit modes with the loving mallet of knfmtbeck2023-07-089-1164/+1342
| | | | ok tb@
* xts128 mode: avoid two -Wshadow warnings in the BIG_ENDIAN code path.tb2023-05-071-5/+5
| | | | Found by, compile tested & ok bluhm.
* Remove CTS modetb2023-04-252-296/+1
| | | | ok jsing
* Add endbr64 where needed by inspection. Passes regresson tests.deraadt2023-04-251-0/+4
| | | | ok jsing, and kind of tb an earlier version
* Cipher text stealing will go away. Mark it for removal.tb2023-04-161-1/+3
| | | | ok jsing
* Use explicit .text instead of .previous to please Windows/MinGW on amd64tb2023-02-231-1/+1
| | | | ok miod
* Use .section .rodata instead of a plain .rodatatb2023-02-091-1/+1
| | | | | | | | 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
* Move all data blocks from .text to .rodata and cleanup up and homogeneize codemiod2023-02-021-16/+5
| | | | responsible from getting the proper address of those blocks.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-09 02:50:56 +0000