summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/crypto_internal.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Improve bit counter handling in MD5.jsing2025-01-191-1/+11
| | | | | | | | | | | | | | | | Like most hashes, MD5 needs to keep count of the number of bits in the message being processed. However, rather than using a 64 bit counter this is implemented using two 32 bit values (which is exposed in the public API). Even with this hurdle, we can still use 64 bit math and let the compiler figure out how to best handle the situation (hopefully avoiding compiler warnings on 16 bit platforms in the process!). On amd64 this code now requires two instructions, instead of the previous five. While here remove a comment that is excessively visible and no longer completely accurate (and if you're going to redefine types like MD5_WORD you kinda need to know what you're doing). ok tb@ (who's going to miss the dear diary style comments)
* Provide constant time comparison functions for size_t.jsing2024-11-081-1/+69
| | | | | | These will be used in an upcoming change. ok beck@ tb@
* Provide crypto_cpu_caps_init() as a CPU capability detection entry point.jsing2024-10-171-1/+3
| | | | | | | This can be overridden on a per-architecture basis. The default version calls OPENSSL_cpuid_setup(), which will be eventually replaced/removed. ok joshua@ tb@
* Reenable AES-NI in libcryptotb2024-09-061-1/+3
| | | | | | | | | | | | | | | | | | | 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...
* Provide and use crypto_arch.h.jsing2024-08-111-1/+3
| | | | | | | | 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@
* Provide constant time operations for uint8_t.jsing2024-04-171-1/+68
| | | | | | These will be used in upcoming changes. ok tb@
* Include stdint.h since we use uint*_t types.jsing2024-03-281-1/+2
|
* Fix function guards.jsing2024-03-261-3/+3
|
* Clean up alignment handling.jsing2023-08-151-1/+32
| | | | | | | | Instead of using HOST_{c2l,l2c} macros, provide and use crypto_load_le32toh() and crypto_store_htole32(). In some cases just use htole32() directly. ok tb@
* Clean up alignment handling for SHA-512.jsing2023-05-271-7/+44
| | | | | | | | | | | This recommits r1.37 of sha512.c, however uses uint8_t * instead of void * for the crypto_load_* functions and primarily uses const uint8_t * to track input, only casting to const SHA_LONG64 * once we know that it is suitably aligned. This prevents the compiler from implying alignment based on type. Tested by tb@ and deraadt@ on platforms with gcc and strict alignment. ok tb@
* backout alignment changes (breaking at least two architectures)deraadt2023-05-191-46/+9
|
* Clean up alignment handling for SHA-512.jsing2023-05-171-9/+46
| | | | | | | | | | | | | | | | | | All assembly implementations are required to perform their own alignment handling. In the case of the C implementation, on strict alignment platforms, unaligned data will be copied into an aligned buffer. However, most platforms then perform byte-by-byte reads (via the PULL64 macros). Instead, remove SHA512_BLOCK_CAN_MANAGE_UNALIGNED_DATA and alignment handling to sha512_block_data_order() - if the data is aligned then simply perform 64 bit loads and then do endian conversion via be64toh(). If the data is unaligned then use memcpy() and be64toh() (in the form of crypto_load_be64toh()). Overall this reduces complexity and can improve performance (on aarch64 we get a ~10% performance gain with aligned input and about ~1-2% gain on armv7), while the same movq/bswapq is generated for amd64 and movl/bswapl for i386. ok tb@
* Provide soon to be used crypto_store_htobe32().jsing2023-04-141-1/+20
| | | | ok tb@
* Provide and use crypto_ro{l,r}_u{32,64}().jsing2023-04-121-1/+33
| | | | | | | | | | | | | | | Various code in libcrypto needs bitwise rotation - rather than defining different versions across the code base, provide a common set that can be reused. Any sensible compiler optimises these to a single instruction where the architecture supports it, which means we can ditch the inline assembly. On the chance that we need to provide a platform specific versions, this follows the approach used in BN where a MD crypto_arch.h header could be added in the future, which would then provide more specific versions of these functions. ok tb@
* Provide and use crypto_store_htobe64().jsing2023-04-121-0/+34
It is common to need to store data in a specific endianness - rather than handrolling and deduplicating code to do this, provide a crypto_store_htobe64() function that converts from host endian to big endian, before storing the data to a location with unknown alignment. ok tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 01:42:49 +0000