A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_8_BASE 2025-05-24T07:07:18+00:00 2025-05-24T07:07:18+00:00 jsing 2025-05-24T07:07:18+00:00 urn:sha1:8ed7978ba9261ae91449f542e06d0cd25c7e1b62 The arm CPU capability detection is uses SIGILL and is unsafe to call from some contexts. Furthermore, this is only useful to detect NEON support, which is then unused on OpenBSD due to __STRICT_ALIGNMENT. Requiring a minimum of ARMv7+VFP+NEON is also not unreasonable. The SHA-1, SHA-256 and SHA-512 (non-NEON) C code performs within ~5% of the assembly, as does RSA when using the C based Montgomery multiplication. The C versions of AES and GHASH code are around ~40-50% of the assembly, howeer if you care about performance you really want to use Chacha20Poly1305 on this platform. This will enable further clean up to proceed. ok joshua@ kinjiro@ tb@ 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-08-11T13:02:39+00:00 jsing 2024-08-11T13:02:39+00:00 urn:sha1:5dcef2b3ea9eb7ace8ed74c27534785fc0b87130 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@ 2024-03-29T11:00:57+00:00 jsing 2024-03-29T11:00:57+00:00 urn:sha1:2f6039e975b851c54c5857fe9253b02da013fb32 Always provide AES_{encrypt,decrypt}() via C functions, which then either use a C implementation or call the assembly implementation. ok tb@ 2024-03-29T07:24:09+00:00 jsing 2024-03-29T07:24:09+00:00 urn:sha1:720ec2c3adcad1ded38a6104e4ca139b4a62ac19 These files are now built on all platforms. 2024-03-29T06:03:21+00:00 jsing 2024-03-29T06:03:21+00:00 urn:sha1:5d94d0325a5b03c1ba85b2e0d51af503a072cc2a This is now built on all platforms. 2024-03-29T04:39:54+00:00 jsing 2024-03-29T04:39:54+00:00 urn:sha1:2c1a87a439933e428607afc0c18d4d12070ae246 Always include aes_core.c and provide AES_set_{encrypt,decrypt}_key() via C functions, which then either use a C implementation or call the assembly implementation. ok tb@ 2024-03-29T02:33:45+00:00 jsing 2024-03-29T02:33:45+00:00 urn:sha1:56504c1b338a0cf1e2340ecd05ecce2ff1b68680 This is now built on all platforms. 2024-03-28T12:52:58+00:00 jsing 2024-03-28T12:52:58+00:00 urn:sha1:c552d9c2f8ca2375f539c9afe37341126127d0f7 2024-03-28T01:57:00+00:00 jsing 2024-03-28T01:57:00+00:00 urn:sha1:ec21b0ca38803c02b86ff3aa3362fce09f349c32 This is now built on all platforms.