A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9_BASE 2026-01-17T16:18:32+00:00 2026-01-17T16:18:32+00:00 jsing 2026-01-17T16:18:32+00:00 urn:sha1:03fc8f9b9ecbb65326348dd8eccc5d22344abefe Make life easier for portable by providing LIBRESSL_USE_.*_ASSEMBLY defines, which enable/disable assembly for a specific algorithm. This means that selected platforms can include the assembly files and specify a define, rather than having to try to patch the crypto_arch.h headers. Discussed with tb@ 2026-01-17T14:53:09+00:00 jsing 2026-01-17T14:53:09+00:00 urn:sha1:fdea186c25361674646de3b0a16b3ad37c8f0ec3 Use the same pattern that is now used for most other code - provide HAVE_MD5_BLOCK_DATA_ORDER and use this to selectively enable source code. 2026-01-17T14:30:37+00:00 jsing 2026-01-17T14:30:37+00:00 urn:sha1:db12bd9b580e2fc1c5c7d3224d2d9d0f534d1b8d Use the same pattern that is now used for most other code - provide HAVE_* defines for functions and use these to selectively enable source code. 2026-01-17T13:55:31+00:00 jsing 2026-01-17T13:55:31+00:00 urn:sha1:1dd1aaafcbe820792a0f2e002a85a22055696509 These have not been used for quite some time. 2025-08-14T15:12:53+00:00 jsing 2025-08-14T15:12:53+00:00 urn:sha1:07bac2b524750c4dfd196516fe31b97d149acde4 2025-06-28T12:39:10+00:00 jsing 2025-06-28T12:39:10+00:00 urn:sha1:48723f4db60f6f8a8ad8424ffe5e0262d30f397c Provide gcm128_amd64.c and gcm128_i386.c, which contain the appropriate gcm128 initialisation and CPU feature tests for the respective platform. This allows for all of the #define spagetti to be removed from gcm128.c and removes one of the two remaining consumers of crypto_cpu_caps_ia32(). ok tb@ 2025-06-15T15:11:50+00:00 jsing 2025-06-15T15:11:50+00:00 urn:sha1:51f804b282da1b0813454f9f6027d3726deea4c7 Currently, the AES-NI code is only integrated into EVP - add code to integrate AES-NI into AES. Rename the assembly provided functions and provide C versions for the original names, which check for AES-NI support and dispatch to the appropriate function. This means that the AES_* public API will now use AES-NI, if available. ok tb@ 2025-06-09T13:51:48+00:00 jsing 2025-06-09T13:51:48+00:00 urn:sha1:083258dce472c3642c1fc04f51099b226a1db816 This no longer does anything on this architecture. ok bcook@ beck@ 2025-04-18T13:19:39+00:00 jsing 2025-04-18T13:19:39+00:00 urn:sha1:710fa3f5ab1ebef2c8c4b9bfdefe9a64dbaef0e5 The bitsliced and vector permutation AES implementations were created around 2009, in attempts to speed up AES on Intel hardware. Both require SSSE3 which existed from around 2006. Intel introduced AES-NI in 2008 and a large percentage of Intel/AMD CPUs made in the last 15 years include it. AES-NI is significantly faster and requires less code. Furthermore, the BS-AES and VP-AES implementations are wired directly into EVP (as is AES-NI currently), which means that any consumers of the AES_* API are not able to benefit from acceleration. Removing these greatly simplifies the EVP AES code - if you just happen to have a CPU that supports SSSE3 but not AES-NI, then you'll now use the regular AES assembly implementations instead. ok kettenis@ 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@