summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/sha (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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@
* Remove duplicate NID definitionstb2023-04-251-11/+1
|
* Remove no longer necessary compat #definestb2023-04-251-6/+1
|
* Add endbr64 where needed by inspection. Passes regresson tests.deraadt2023-04-252-0/+5
| | | | ok jsing, and kind of tb an earlier version
* Provide EVP methods for SHA3 224/256/384/512.jsing2023-04-161-1/+11
| | | | ok tb@
* Provide EVP methods for SHA512/224 and SHA512/256.jsing2023-04-161-1/+6
| | | | ok tb@
* Bounds check mdlen that is passed to sha3_init().jsing2023-04-161-2/+5
| | | | While here, use KECCAK_BYTE_WIDTH instead of hardcoding the value.
* Use size_t rather than int.jsing2023-04-152-13/+13
| | | | Also buy a vowel for rsiz.
* Add SHA3 digest length define that was previously missed.jsing2023-04-151-1/+2
|
* Remove sha3() function, which will not be used or exposed.jsing2023-04-152-16/+2
|
* Mark sha3_keccakf() as static and remove prototype from header.jsing2023-04-152-5/+3
|
* Use memset() to zero the context, instead of zeroing manually.jsing2023-04-151-5/+3
|
* Provide SHA3 length related defines.jsing2023-04-151-1/+27
| | | | | These will make EVP integration easier, as well as being used in the SHA3 implementation itself.
* Use the same byte order tests as we do elsewhere in libcrypto.jsing2023-04-151-3/+5
|
* Rename SHA3 context struct field from 'st' to 'state'.jsing2023-04-152-15/+15
|
* Rename SHA3 context to align with existing code.jsing2023-04-152-14/+14
|
* Move some defines out of the sha3_internal.h header.jsing2023-04-152-10/+6
|
* Revise header guards.jsing2023-04-151-4/+4
|
* Pull constant tables out of sha3_keccakf().jsing2023-04-151-24/+24
|
* Strip and reformat comments.jsing2023-04-152-44/+14
| | | | | Remove various comments that are unhelpful or obvious. Reformat remaining comments per style(9).
* Apply style(9) (first pass).jsing2023-04-152-146/+152
|
* Import sha3_internal.h.jsing2023-04-151-2/+2
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-26 10:02:51 +0000