summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/sha/sha512.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Replace Makefile based SHA*_ASM defines with HAVE_SHA_* defines.jsing2025-02-141-7/+13
| | | | | | | | | | | | | | | | 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@
* Remove support for static buffers in HMAC/digeststb2024-06-011-9/+1
| | | | | | | | | | | | | | | | | | 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
* Hide symbols in shabeck2023-07-081-1/+10
| | | | ok tb@
* Demacro SHA-512.jsing2023-07-021-54/+112
| | | | | | | | | | | | | | | 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@
* Clean up alignment handling for SHA-512.jsing2023-05-271-73/+52
| | | | | | | | | | | 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@
* backout alignment changes (breaking at least two architectures)deraadt2023-05-191-49/+72
|
* Clean up alignment handling for SHA-512.jsing2023-05-171-72/+49
| | | | | | | | | | | | | | | | | | 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@
* Clean up SHA-512 input handling and round macros.jsing2023-05-161-47/+49
| | | | | | | | | | | 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@
* Reduce the number of SHA-512 C implementations from three to one.jsing2023-05-121-134/+1
| | | | | | | | | | | | | | | | | 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@
* Add support for truncated SHA512 variants.jsing2023-04-141-2/+79
| | | | | | | 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@
* Use memset() and only initialise non-zero struct members.jsing2023-04-141-7/+7
| | | | ok tb@
* Provide and use crypto_ro{l,r}_u{32,64}().jsing2023-04-121-14/+2
| | | | | | | | | | | | | | | Various code in libcrypto needs bitwise rotation - rather than defining different versions across the code base, provide a common set that can be reused. Any sensible compiler optimises these to a single instruction where the architecture supports it, which means we can ditch the inline assembly. On the chance that we need to provide a platform specific versions, this follows the approach used in BN where a MD crypto_arch.h header could be added in the future, which would then provide more specific versions of these functions. ok tb@
* Provide and use crypto_store_htobe64().jsing2023-04-121-23/+9
| | | | | | | | | It is common to need to store data in a specific endianness - rather than handrolling and deduplicating code to do this, provide a crypto_store_htobe64() function that converts from host endian to big endian, before storing the data to a location with unknown alignment. ok tb@
* Recommit jsing's r1.27 - portable is readytb2023-04-111-23/+4
| | | | | | Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64(). Thanks to tobhe for providing most of the fix via openiked-portable
* Back out r1.27 using htobe64() - apparently some OS don't have it.tb2023-04-111-4/+23
| | | | ok jsing
* Simplify handling of big vs little endian.jsing2023-04-111-40/+5
| | | | | | | Rather than sprinkling BYTE_ORDER checks throughout the implementation, always define PULL64 - on big endian platforms it just becomes a no-op. ok tb@
* Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().jsing2023-04-111-23/+4
| | | | ok tb@
* Omit sha512_block_data_order() prototype when assembly is not being used.jsing2023-04-111-4/+3
| | | | | | | | | In the case that the pure C implementation of SHA512 is being used, the prototype is unnecessary as the function is declared static and exists in dependency order. Simply omit the prototype rather than using #ifndef to toggle the static prefix. ok tb@
* Remove less than useful implementation notes.jsing2023-04-111-36/+1
| | | | ok tb@
* Whitespace fixes.jsing2023-03-291-68/+68
| | | | | | | Mechanically replace "a,b" with "a, b", followed with some manual indentation clean up. No change in generated assembly.
* Use multiple statements instead of a statement with multiple expressions.jsing2023-03-291-4/+5
| | | | No change in generated assembly.
* Reorder functions/code.jsing2023-03-271-238/+238
| | | | No intended functional change.
* Tidy includes.jsing2023-03-271-5/+4
|
* Add license to sha256.c/sha512.c.jsing2023-03-261-3/+50
|
* Use multiple statements instead of comma separated expressions.jsing2023-03-261-24/+33
| | | | No change to generated assembly.
* Add some blank lines for readability, along with some more style(9) tweaks.jsing2023-03-261-3/+9
|
* Whack sha with a style(9) stick.jsing2023-03-261-326/+422
| | | | No change in generated assembly.
* Switch to <endian.h> from <machine/endian.h> for better portability.bcook2021-11-091-3/+2
| | | | ok tb@
* Remove I386_ONLY define. It was only used to prefer amiod2016-11-041-12/+1
| | | | | | | faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in the SHA512 code, and had not been enabled in years, if at all. ok tom@ bcook@
* Correct spelling of OPENSSL_cleanse.jsing2015-09-101-3/+3
| | | | ok miod@
* Only import cryptlib.h in the four source files that actually need it.jsing2014-07-111-4/+2
| | | | | | | | Remove the openssl public includes from cryptlib.h and add a small number of includes into the source files that actually need them. While here, also sort/group/tidy the includes. ok beck@ miod@
* Explicitly include <openssl/opensslconf.h> in every file that referencesjsing2014-07-101-4/+8
| | | | | | | | | an OPENSSL_NO_* define. This avoids relying on something else pulling it in for us, plus it fixes several cases where the #ifndef OPENSSL_NO_XYZ is never going to do anything, since OPENSSL_NO_XYZ will never defined, due to the fact that opensslconf.h has not been included. This also includes some miscellaneous sorting/tidying of headers.
* Remove leading underscore from _BYTE_ORDER and _{LITTLE,BIG}_ENDIAN, to bemiod2014-07-091-4/+4
| | | | | more friendly to systems where the underscore flavours may be defined as empty. Found the hard way be bcook@; joint brainstrom with bcook beck and guenther
* remove unused, private version strings except SSL_version_strbcook2014-07-091-3/+1
| | | | | | Also remove unused des_ver.h, which exports some of these strings, but is not installed. ok miod@ tedu@
* tags as requested by miod and teduderaadt2014-06-121-1/+1
|
* Get __STRICT_ALIGNMENT from <machine/endian.h> and decide upon it, rathermiod2014-05-071-4/+1
| | | | | | | | | | | | | | than defining it for not (i386 and amd64 (and sometimes s390)) only. Compile-time tests remain compile-time tests, and runtime-test remain runtime-test instead of being converted to compile-time tests, per matthew@'s explicit demand (rationale: this makes sure the compiler checks your code even if you won't run it). No functional change except on s390 (which we don't run on) and vax (which we run on, but noone cares about) ok matthew@
* Remove fips_md_init() macro indirection for digest algorithms, used by themiod2014-05-011-2/+2
| | | | | | | OpenSSL FIPS module to prevent forbidden digests to be allowed. No functional change but readability. ok deraadt@
* Unifdef -UPEDANTIC. ok beck@ tedu@miod2014-04-231-20/+12
|
* Do not ask the user to pass either -DB_ENDIAN or -DL_ENDIAN to the compiler,miod2014-04-181-3/+4
| | | | | | | but rather figure out the endianness from <machine/endian.h> automagically; help from guenther@ ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'
* Get rid of MS Visual C compiler and Intel C compiler specific defines.miod2014-04-171-30/+0
|
* Remove support for big-endian i386 and amd64.miod2014-04-171-7/+1
| | | | | | | | | | | | | Before someone suggests the OpenSSL people are junkies, here is what they mention about this: /* Most will argue that x86_64 is always little-endian. Well, * yes, but then we have stratus.com who has modified gcc to * "emulate" big-endian on x86. Is there evidence that they * [or somebody else] won't do same for x86_64? Naturally no. * And this line is waiting ready for that brave soul:-) */ So, yes, they are on drugs. But they are not alone, the stratus.com people are, too.
* Reliability fix for SHA384 SSL/TLS ciphers on strict alignmentjca2013-12-191-1/+8
| | | | | | | | | architectures. ok miod@ djm@ Upstream patch: commit cdd1acd788020d2c525331da1712ada778f1373c Author: Andy Polyakov <appro@openssl.org> Date: Wed Dec 18 21:27:35 2013 +0100
* import OpenSSL-1.0.1cdjm2012-10-131-49/+5
|
* import OpenSSL-1.0.0adjm2010-10-011-45/+139
|
* import openssl-0.9.8jdjm2009-01-091-1/+11
|
* import of OpenSSL 0.9.8hdjm2008-09-061-0/+537
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-28 11:28:32 +0000