A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v4.2.1 2025-08-17T08:04:25+00:00 2025-08-17T08:04:25+00:00 jsing 2025-08-17T08:04:25+00:00 urn:sha1:c9f6ed45b268d1c6b5608ff56379e3b051625806 The RC4_CHUNK related code is intended to process native word sized chunks if the input and output are naturally aligned. However, RC4_CHUNK is currently a mess of machine dependent defines. Replace this with uint64_t on all architectures - 64 bit architectures will be happy with this and on 32 bit architectures the compiler can decompose this into multiple 32 bit operations. Provide separate rc4_chunk() implementations for big and little endian, since not all architectures have a byte swap instruction that would make this a cheap conversion. Thanks to gkoehler@ and tb@ for testing on big endian. ok tb@ 2025-08-14T14:55:43+00:00 jsing 2025-08-14T14:55:43+00:00 urn:sha1:3d3d845569e98c5b0f11899e4958cca728c8b99a Provide a static inline rc4_step() function that replaces the near identical RC4_STEP and RC4_LOOP macros. Simplify the processing loop and use for loops with small constants, which the compiler can unroll if it wants to do so. Inline the SK_LOOP macro in rc4_set_key_internal(), also using a small loop that the compiler will most likely unroll. ok tb@ 2025-06-09T14:37:49+00:00 tb 2025-06-09T14:37:49+00:00 urn:sha1:77890745eac7fbfd51208f10c1759d6998f0692b Most of the constants here are only defined if a specific header is in scope. So move the machine-independent macros to those headers and lose the header guards. Most of these should actually be typedefs but let's change this when we're bumping the major since this technically has ABI impact. IDEA_INT RC2_INT and RC4_INT are always unsigned int DES_LONG is always unsigned int except on i386 This preserves the existing situation on OpenBSD. If you're using portable on i386 with a compiler that does not define __i386__, there's an ABI break. ok jsing 2025-01-27T14:02:32+00:00 jsing 2025-01-27T14:02:32+00:00 urn:sha1:d97873f8db01cd052f45675db2ed3d9584c93c44 The RC4_INDEX define switches between base pointer indexing and per-byte pointer increment. This supposedly made a huge difference to performance on x86 at some point, however compilers have improved somewhat since then. There is no change (or effectively no change) in generated assembly on a the majority of LLVM platforms and even when there is some change (e.g. aarch64), there is no noticable performance difference. Simplify the (still messy) macros/code and mop up RC4_INDEX. ok tb@ 2025-01-25T17:59:44+00:00 tb 2025-01-25T17:59:44+00:00 urn:sha1:5d52abc236226c5a47c36b07e2256e77141e373a discussed with jsing 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-28T12:11:26+00:00 jsing 2024-03-28T12:11:26+00:00 urn:sha1:e45946a7bbb9930880549017ee5a85918edc1d00 2024-03-28T08:18:13+00:00 joshua 2024-03-28T08:18:13+00:00 urn:sha1:f62594c39479115536dfc56a66c3f22e527f1c38 ok jsing tb beck 2024-03-28T01:49:29+00:00 jsing 2024-03-28T01:49:29+00:00 urn:sha1:ee4f7c5caf1aa306d0a5b443f5c9133ae646925b Rather than having public API switch between C and assembly, always use C functions as entry points, which then call an assembly implementation (if available). This makes it significantly easier to deal with symbol aliasing/namespaces and it also means we benefit from vulnerability prevention provided by the C compiler. Rename the assembly generated functions from RC4() to rc4_internal() and RC4_set_key() to rc4_set_key_internal(). Always include rc4.c and change it to use defines that are similar to those used in BN. ok beck@ joshua@ tb@ 2024-03-27T12:59:12+00:00 jsing 2024-03-27T12:59:12+00:00 urn:sha1:ddf23e9f98c2df931e1bb028e49b3087001d98cc This is already disabled since it is "about 35% slower than C code".