openbsd/src/lib/libcrypto/sha, branch libressl-v4.2.1A mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=libressl-v4.2.12025-06-28T12:51:08+00:00Provide accelerated SHA-1 for aarch64.2025-06-28T12:51:08+00:00jsing2025-06-28T12:51:08+00:00urn:sha1:8d0be76398371402b3426575c7326b6e08b0e023
Provide an assembly implementation of SHA-1 for aarch64 using the ARM
Cryptographic Extension (CE). This results in around a 2x speed up for
larger block sizes.
ok tb@
Make OPENSSL_IA32_SSE2 the default for i386 and remove the flag.2025-06-09T14:28:34+00:00jsing2025-06-09T14:28:34+00:00urn:sha1:951cd4503ff3c4cc93c1a36cf06138b1ddd739d7
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@
Remove GNU assembler version check.2025-06-09T13:58:28+00:00jsing2025-06-09T13:58:28+00:00urn:sha1:d8ae322f91ae730f31b750787e0180588dab36dc
GNU assembler version 2.19 was released in 2014, so it does not seem
unreasonable to expect that we have an assembler that supports AVX.
Furthermore, the current check fails on LLVM.
ok bcook@ beck@
Use 'ctx' for sha3_ctx variables, rather than the less readable 'c'.2025-04-18T07:36:11+00:00jsing2025-04-18T07:36:11+00:00urn:sha1:40f74488b8ad99303861a7ad88abf6108df59fb0
ok tb@
Pull casts from void * to uint8_t * up to variables, rather than inline.2025-04-18T07:27:42+00:00jsing2025-04-18T07:27:42+00:00urn:sha1:b9a0523d97444dc48412549cc52bb57d6dcd7d7e
ok tb@
Use two temporary variables in sha3_keccakf(), rather than reusing bc[0].2025-04-18T07:23:53+00:00jsing2025-04-18T07:23:53+00:00urn:sha1:0cfcf98fa69ee0b31f87737228a909957c333871
ok tb@
Use crypto_rol_u64() instead of a separate ROTL64 define.2025-04-18T07:19:48+00:00jsing2025-04-18T07:19:48+00:00urn:sha1:8f837a7afcb2f30d9e5cfd02b41d379d1e356f89
ok tb@
Provide an accelerated SHA-512 assembly implementation for aarch64.2025-03-12T14:13:41+00:00jsing2025-03-12T14:13:41+00:00urn:sha1:dcd1700591c767d997c903eba3f3953d562bf23a
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.2025-03-12T12:53:33+00:00jsing2025-03-12T12:53:33+00:00urn:sha1:76a201e2d50dcc1de518d41ad51e8f894f056407
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.2025-03-07T14:21:22+00:00jsing2025-03-07T14:21:22+00:00urn:sha1:504b1d708a6f318c44655b84b6f33ec1734e0375
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@