summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/sha (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Inline HASH_MAKE_STRING for SHA256.jsing2023-05-281-34/+37
| | | | No change to generated assembly.
* Implement SHA256_{Update,Transform,Final}() directly in sha256.c.jsing2023-05-271-4/+103
| | | | | | | | | | m32_common.h is a typical OpenSSL macro horror show - copy the update, transform and final functions from md32_common.h, manually expanding the macros for SHA256. This will allow for further clean up to occur. No change in generated assembly. 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@
* Remove duplicate NID definitionstb2023-04-251-11/+1
|
* Remove no longer necessary compat #definestb2023-04-251-6/+1
|
* Add endbr64 where needed by inspection. Passes regresson tests.deraadt2023-04-252-0/+5
| | | | ok jsing, and kind of tb an earlier version
* Provide EVP methods for SHA3 224/256/384/512.jsing2023-04-161-1/+11
| | | | ok tb@
* Provide EVP methods for SHA512/224 and SHA512/256.jsing2023-04-161-1/+6
| | | | ok tb@
* Bounds check mdlen that is passed to sha3_init().jsing2023-04-161-2/+5
| | | | While here, use KECCAK_BYTE_WIDTH instead of hardcoding the value.
* Use size_t rather than int.jsing2023-04-152-13/+13
| | | | Also buy a vowel for rsiz.
* Add SHA3 digest length define that was previously missed.jsing2023-04-151-1/+2
|
* Remove sha3() function, which will not be used or exposed.jsing2023-04-152-16/+2
|
* Mark sha3_keccakf() as static and remove prototype from header.jsing2023-04-152-5/+3
|
* Use memset() to zero the context, instead of zeroing manually.jsing2023-04-151-5/+3
|
* Provide SHA3 length related defines.jsing2023-04-151-1/+27
| | | | | These will make EVP integration easier, as well as being used in the SHA3 implementation itself.
* Use the same byte order tests as we do elsewhere in libcrypto.jsing2023-04-151-3/+5
|
* Rename SHA3 context struct field from 'st' to 'state'.jsing2023-04-152-15/+15
|
* Rename SHA3 context to align with existing code.jsing2023-04-152-14/+14
|
* Move some defines out of the sha3_internal.h header.jsing2023-04-152-10/+6
|
* Revise header guards.jsing2023-04-151-4/+4
|
* Pull constant tables out of sha3_keccakf().jsing2023-04-151-24/+24
|
* Strip and reformat comments.jsing2023-04-152-44/+14
| | | | | Remove various comments that are unhelpful or obvious. Reformat remaining comments per style(9).
* Apply style(9) (first pass).jsing2023-04-152-146/+152
|
* Import sha3_internal.h.jsing2023-04-151-2/+2
|
* Add license to sha3 files.jsing2023-04-152-0/+50
|
* Import tiny_sha3jsing2023-04-152-0/+238
| | | | | | This is a minimal and readable SHA3 implementation. ok tb@
* Add support for truncated SHA512 variants.jsing2023-04-142-2/+115
| | | | | | | 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@
* Remove now unused sha_local.h.jsing2023-04-121-419/+0
|
* 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
* Consolidate sha1 into a single file.jsing2023-04-112-88/+21
|
* 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@
* More whitespace fixes.jsing2023-03-291-51/+51
| | | | | | Another set of mechnical replacements for "a,b" with "a, b". No change in generated assembly.
* Whitespace fixes.jsing2023-03-291-133/+133
| | | | | | Mechanically replace "a,b" with "a, b". No change to generated assembly.
* 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.
* Mop up MD32_XARRAY from SHA1.jsing2023-03-291-162/+135
| | | | | | | | | MD32_XARRAY (formerly SHA_XARRAY) was added as a workaround for a broken HP C compiler (circa 1999). Clean it up to simplify the code. No change in generated assembly. ok miod@ tb@
* Inline initial hash data values for SHA1.jsing2023-03-291-13/+9
| | | | | | This follows what is done for other SHA implementations. ok miod@ tb@
* Reorder functions/code.jsing2023-03-271-238/+238
| | | | No intended functional change.
* Tidy includes.jsing2023-03-271-5/+4
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-17 18:53:04 +0000