A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9_BASE 2025-02-14T12:01:58+00:00 2025-02-14T12:01:58+00:00 jsing 2025-02-14T12:01:58+00:00 urn:sha1:a89810379a758c9cd27af2462547dc646dcfaa61 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@ 2024-06-01T07:36:17+00:00 tb 2024-06-01T07:36:17+00:00 urn:sha1:0cd26255605cab2a8643bb8585c4148069240e3c 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 2023-07-08T12:24:10+00:00 beck 2023-07-08T12:24:10+00:00 urn:sha1:f46ac389a5f2c573c854a6c2b50156ca974ea892 ok tb@ 2023-07-02T14:57:58+00:00 jsing 2023-07-02T14:57:58+00:00 urn:sha1:a67ddc8be74144f826c75dc1fb2893972819b2f3 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@ 2023-05-27T09:18:17+00:00 jsing 2023-05-27T09:18:17+00:00 urn:sha1:fce75c36c6fda1fa1488c600abe6490c27e90d75 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@ 2023-05-19T00:54:28+00:00 deraadt 2023-05-19T00:54:28+00:00 urn:sha1:3dc51b1807e9a69624721300010e6e6ce16d5709 2023-05-17T06:37:14+00:00 jsing 2023-05-17T06:37:14+00:00 urn:sha1:5d9c22eaef33c903e296cd1e7e2c0592e3286672 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@ 2023-05-16T07:04:57+00:00 jsing 2023-05-16T07:04:57+00:00 urn:sha1:1b444f75a951b233b38acfea196d180bbb134432 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@ 2023-05-12T10:10:55+00:00 jsing 2023-05-12T10:10:55+00:00 urn:sha1:a16324e54a8b77c1b2e74836e3e7d439d2ed63fd 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@ 2023-04-14T10:45:15+00:00 jsing 2023-04-14T10:45:15+00:00 urn:sha1:cf8c23344c650c985a16207e78fc8f4b62e4159f This adds support for SHA512/224 and SHA512/256, as specified in FIPS FIPS 180-4. These are truncated versions of the SHA512 hash. ok tb@