Files
Adam Langley 5622da92e1 Pack SHA-512 and BLAKE2b a little more tightly.
Honestly, we don't actually need to support hashing more than 2**64
bytes on a single machine, so we certainly don't need to support 2**128
bytes. Thus pack these structures a little better by supporting only
2**96 bytes. This removes 8 bytes from these structures and thus 24
bytes from an HMAC_CTX.

It's possible to pack SHA-512 even tighter: the final byte of the block
buffer isn't used between calls. It can be repurposed to store the
buffer length (in the lower seven bits) and an "is SHA-384" flag in the
MSB. That saves another eight bytes.

But the same trick doesn't work for BLAKE2b because it hashes in a
"final block" flag and thus needs to know whether there's more data
coming before hashing a block. Thus it uses all 128 bytes for storage.

So while we can pack SHA-512 tighter, BLAKE2b would still keep
EVP_MAX_MD_DATA_SIZE the same.

Pleasingly, this seems net-positive on benchmarks. (Or, at least, not
negative.)

Before:

Did 49145000 SHA-512 (16 bytes) operations in 5000055us (9828891.9 ops/sec): 157.3 MB/s
Did 17905000 SHA-512 (256 bytes) operations in 5000134us (3580904.0 ops/sec): 916.7 MB/s
Did 5091000 SHA-512 (1350 bytes) operations in 5000183us (1018162.7 ops/sec): 1374.5 MB/s
Did 871000 SHA-512 (8192 bytes) operations in 5004110us (174056.9 ops/sec): 1425.9 MB/s
Did 440000 SHA-512 (16384 bytes) operations in 5008994us (87842.0 ops/sec): 1439.2 MB/s

After:

Did 50435000 SHA-512 (16 bytes) operations in 5000060us (10086879.0 ops/sec): 161.4 MB/s
Did 18218000 SHA-512 (256 bytes) operations in 5000068us (3643550.4 ops/sec): 932.7 MB/s
Did 5126000 SHA-512 (1350 bytes) operations in 5000588us (1025079.5 ops/sec): 1383.9 MB/s
Did 872000 SHA-512 (8192 bytes) operations in 5002028us (174329.3 ops/sec): 1428.1 MB/s
Did 440000 SHA-512 (16384 bytes) operations in 5004069us (87928.4 ops/sec): 1440.6 MB/s

Change-Id: Ib996d82cff3e959993a9e553a688766c2e9052fb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79508
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2025-06-05 14:47:57 -07:00
..