summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/sha (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Provide an accelerated SHA-512 assembly implementation for aarch64.jsing7 days2-0/+346
| | | | | | | | | | This provides a SHA-512 assembly implementation that makes use of the ARM Cryptographic Extension (CE), which is found on many arm64 CPUs. This gives a performance gain of up to 2.5x on an Apple M2 (dependent on block size). If an aarch64 machine does not have SHA512 support, then we'll fall back to using the existing C implementation. ok kettenis@ tb@
* Use .arch rather than .cpu for sha2 instructions.jsing8 days1-2/+2
| | | | | | | We have code that targets a specific architecture level, hence .arch makes more sense here than .cpu. Suggested by kettenis@
* Provide an accelerated SHA-256 assembly implementation for aarch64.jsing12 days2-0/+223
| | | | | | | | | | This provides a SHA-256 assembly implementation that makes use of the ARM Cryptographic Extension (CE), which is found on many arm64 CPUs. This gives a performance gain of up to 7.5x on an Apple M2 (dependent on block size). If an aarch64 machine does not have SHA2 support, then we'll fall back to using the existing C implementation. ok kettenis@ tb@
* Replace Makefile based SHA*_ASM defines with HAVE_SHA_* defines.jsing2025-02-143-20/+40
| | | | | | | | | | | | | | | | Currently, SHA{1,256,512}_ASM defines are used to remove the C implementation of sha{1,256,512}_block_data_order() when it is provided by assembly. However, this prevents the C implementation from being used as a fallback. Rename the C sha*_block_data_order() to sha*_block_generic() and provide a sha*_block_data_order() that calls sha*_block_generic(). Replace the Makefile based SHA*_ASM defines with two HAVE_SHA_* defines that allow these functions to be compiled in or removed, such that machine specific verisons can be provided. This should effectively be a no-op on any platform that defined SHA{1,256,512}_ASM. ok tb@
* Remove #error if OPENSSL_NO_FOO is definedtb2025-01-251-5/+1
| | | | discussed with jsing
* Use name instead of register.jsing2025-01-181-3/+3
|
* Provide a SHA-1 assembly implementation for amd64 using SHA-NI.jsing2024-12-062-1/+177
| | | | | | | | This provides a SHA-1 assembly implementation for amd64, which uses the Intel SHA Extensions (aka SHA New Instructions or SHA-NI). This provides a 2-2.5x performance gain on some Intel CPUs and many AMD CPUs. ok tb@
* Another now unused perlasm script can bite the dust.jsing2024-12-041-1267/+0
|
* Provide a replacement assembly implementation for SHA-1 on amd64.jsing2024-12-042-0/+342
| | | | | | | | | | | | | As already done for SHA-256 and SHA-512, replace the perlasm generated SHA-1 assembly implementation with one that is actually readable. Call the assembly implementation from a C wrapper that can, in the future, dispatch to alternate implementations. On a modern CPU the performance is around 5% faster than the base implementation generated by sha1-x86_64.pl, however it is around 15% slower than the excessively complex SSSE2/AVX version that is also generated by the same script (a SHA-NI version will greatly outperform this and is much cleaner/simpler). ok tb@
* Simplify endian handling in SHA-3.jsing2024-11-231-26/+5
| | | | | | | | | | Rather than having blocks of code that are conditional on BYTE_ORDER != LITTLE_ENDIAN, use le64toh() and htole64() unconditionally. In the case of a little endian platform, the compiler will optimise this away, while on a big endian platform we'll either end up with better code or the same code than we have currently. ok tb@
* Provide a SHA-256 assembly implementation for amd64 using SHA-NI.jsing2024-11-162-1/+218
| | | | | | | | This provides a SHA-256 assembly implementation for amd64, which uses the Intel SHA Extensions (aka SHA New Instructions or SHA-NI). This provides a 3-5x performance gain on some Intel CPUs and many AMD CPUs. ok tb@
* Remove sha512-x86_64.pl.jsing2024-11-161-347/+0
| | | | | Now that we have replacement SHA-256 and SHA-512 assembly implementations for amd64, sha512-x86_64.pl can go the way of the dodo.
* Provide a replacement assembly implementation for SHA-512 on amd64.jsing2024-11-162-0/+333
| | | | | | | | Replace the perlasm generated SHA-512 assembly with a more readable version and the same C wrapper introduced for SHA-256. As for SHA-256, on a modern CPU the performance is largely the same. ok tb@
* Specify size for K256 symbol.jsing2024-11-161-1/+2
| | | | Missing sizes spotted by guenther@
* Use multipliers for stack offsets and tweak comment.jsing2024-11-121-9/+9
|
* Provide a replacement assembly implementation for SHA-256 on amd64.jsing2024-11-082-0/+327
| | | | | | | | | | | | | Replace the perlasm generated SHA-256 assembly implementation with one that is actually readable. Call the assembly implementation from a C wrapper that can, in the future, dispatch to alternate implementations. Performance is similar (or even better) on modern CPUs, while somewhat slower on older CPUs (this is in part due to the wrapper, the impact of which is more noticable with small block sizes). Thanks to gkoehler@ and tb@ for testing. ok tb@
* Missed SHA224() in previous: reverse order of attributestb2024-06-011-3/+3
|
* Reverse order of attributestb2024-06-011-9/+9
| | | | requested by jsing on review
* Remove support for static buffers in HMAC/digeststb2024-06-014-24/+9
| | | | | | | | | | | | | | | | | | HMAC() and the one-step digests used to support passing a NULL buffer and would return the digest in a static buffer. This design is firmly from the nineties, not thread safe and it saves callers a single line. The few ports that used to rely this were fixed with patches sent to non-hostile (and non-dead) upstreams. It's early enough in the release cycle that remaining uses hidden from the compiler should be caught, at least the ones that matter. There won't be that many since BoringSSL removed this feature in 2017. https://boringssl-review.googlesource.com/14528 Add non-null attributes to the headers and add a few missing bounded attributes. ok beck jsing
* Demacro sha1.jsing2024-03-281-164/+252
| | | | | | | | | Replace macros with static inline functions and use names that follow the spec more closely. Unlike SHA256/SHA512, the functions and constants do not align with the number of words loaded, which means we cannot easily loop and just end up just unrolling everything. ok joshua@ tb@
* Fix line wrapping.jsing2024-03-281-6/+4
|
* Rework input and output handling for sha1.jsing2024-03-261-128/+79
| | | | | | | | Use be32toh(), htobe32() and crypto_{load,store}_htobe32() as appropriate. Also use the same while() loop that is used for other hash functions. ok joshua@ tb@
* Replace uses of endbr64 with _CET_ENDBR from cet.htb2024-02-242-5/+5
| | | | | | | | | 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
* Stop including md32_common.h.jsing2023-08-111-15/+1
| | | | | Now that we're no longer dependent on md32_common.h, stop including it. Remove various defines that only existed for md32_common.h usage.
* Demacro sha256.jsing2023-08-111-49/+114
| | | | | | | | | | | | | | Replace macros with static inline functions, as well as writing out the variable rotations instead of trying to outsmart the compiler. Also pull the message schedule update up and complete it prior to commencement of the round. Also use rotate right, rather than transposed rotate left. Overall this is more readable and more closely follows the specification. On some platforms (e.g. aarch64) there is no noteable change in performance, while on others there is a significant improvement (more than 25% on arm). ok miod@ tb@
* Remove MD32_REG_T.jsing2023-08-102-5/+5
| | | | | | | | | This is a hack that is only enabled on a handful of 64 bit platforms, as a workaround for poor compiler optimisation. If you're running an archiac compiler on an archiac architecture, then you can deal with slightly lower performance. ok tb@
* Hide symbols in shabeck2023-07-083-3/+26
| | | | ok tb@
* Remove unused SHA-1 implementation.jsing2023-07-081-86/+1
|
* Remove now unnecessary "do { } while (0)"jsing2023-07-081-4/+2
|
* Inline HASH_MAKE_STRING macro.jsing2023-07-081-15/+14
| | | | No change to generated assembly.
* Reorder functions.jsing2023-07-081-113/+113
| | | | No functional change.
* style(9)jsing2023-07-081-36/+33
|
* Implement SHA1_{Update,Transform,Final}() directly in sha1.c.jsing2023-07-071-5/+104
| | | | | | | | Copy the update, transform and final functions from md32_common.h, manually expanding the macros for SHA1. This will allow for further clean up to occur. No change in generated assembly.
* Clean up alignment handling for SHA-256.jsing2023-07-071-63/+43
| | | | | | | If input data is 32 bit aligned use be32toh() directly, otherwise use crypto_load_be32toh(), cleaning up all of the HOST_c2l() usage. ok beck@
* Clean up SHA-256 input handling and round macros.jsing2023-07-071-72/+58
| | | | | | | Avoid reach around and initialisation outside of the macro, cleaning up the call sites to remove the initialisation. ok beck@
* Remove unused SHA-256 implementation.jsing2023-07-071-71/+1
| | | | ok beck@
* Replace HOST_l2c() with htob32() or crypto_store_htobe32().jsing2023-07-071-17/+15
| | | | ok beck@
* Demacro SHA-512.jsing2023-07-021-54/+112
| | | | | | | | | | | | | | | Use static inline functions instead of macros to implement SHA-512. At the same time, make two key changes - firstly, rather than trying to outsmart the compiler and shuffle variables around, write the algorithm the way it is documented and actually swap the variable contents. Secondly, instead of interleaving the message schedule update and the round, do the full message schedule update first, then process the round. Overall, we get safer and more readable code. Additionally, the compiler can generate smaller and faster code (with a gain of 5-10% across a range of architectures). ok beck@ tb@
* Sprinkle some style(9).jsing2023-05-281-15/+15
|
* Expand occurrences of HASH_CTX that were previously missed.jsing2023-05-281-4/+5
| | | | No change in generated assembly.
* Reorder functions.jsing2023-05-281-214/+214
| | | | No intended functional change.
* Clean up includes.jsing2023-05-281-6/+5
|
* Remove now unnecessary do {} while(0);jsing2023-05-281-3/+1
|
* Inline HASH_MAKE_STRING for SHA256.jsing2023-05-281-34/+37
| | | | No change to generated assembly.
* Implement SHA256_{Update,Transform,Final}() directly in sha256.c.jsing2023-05-271-4/+103
| | | | | | | | | | m32_common.h is a typical OpenSSL macro horror show - copy the update, transform and final functions from md32_common.h, manually expanding the macros for SHA256. This will allow for further clean up to occur. No change in generated assembly. ok beck@ tb@
* Clean up alignment handling for SHA-512.jsing2023-05-271-73/+52
| | | | | | | | | | | 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-49/+72
|
* Clean up alignment handling for SHA-512.jsing2023-05-171-72/+49
| | | | | | | | | | | | | | | | | | 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@
* Clean up SHA-512 input handling and round macros.jsing2023-05-161-47/+49
| | | | | | | | | | | Avoid reach around and initialisation outside of the macro, cleaning up the call sites to remove the initialisation. Use a T2 variable to more closely follow the documented algorithm and remove the gorgeous compound statement X = Y += A + B + C. There is no change to the clang generated assembly on aarch64. ok tb@
* Reduce the number of SHA-512 C implementations from three to one.jsing2023-05-121-134/+1
| | | | | | | | | | | | | | | | | We currently have three C implementations for SHA-512 - a version that is optimised for CPUs with minimal registers (specifically i386), a regular implementation and a semi-unrolled implementation. Testing on a ~15 year old i386 CPU, the fastest version is actually the semi-unrolled version (not to mention that we still currently have an i586 assembly implementation that is used on i386 instead...). More decent architectures do not seem to care between the regular and semi-unrolled version, presumably since they are effectively doing the same thing in hardware during execution. Remove all except the semi-unrolled version. ok tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 01:02:20 +0000