Hacker News Reader

Comment by cyphar | Hacker News Reader

The oddity is that I believe sha512 uses 64-bit words while sha256 uses 32-bit words. So on 64 bit hardware sha512 will be faster (presumably because using the 32 bit registers is slower somehow, I don't know). This is why ZFS is adding support for sha512/256 as it's Merkel tree hashing function.

View on HN

SHA512 eats data 512 bits at a time, while SHA256 eats it 256 bits at time. Both internally use 8 "registers", which are either 64 or 32 bits wide. Assuming you have the hardware registers to match, this would make SHA512 about twice as fast. But internally, it mixes data using 80 rounds, vs 64 for SHA256, so the speedup isn't quite 2x.

For the sake of pedantry, SHA-512 eats 1024 bits, resp. 512 bits for SHA-256, at a time. It's the chaining variables that are of those lengths.

That fits with my understanding. What I don't know is how this interacts with the acceleration functionality the chip has. For instance, do the instructions end up being "please do sha256 on this data", or are they closer to AES-NI where it's "please perform one round of an AES encryption flow".

Judging from the source code[1] in the author's repository, it is the latter. (what I see is: perform 96 instructions, then subtract 64 from the message length, and repeat until the message length is 0)

Intel seems to be the same way [2](2013) - i.e. looping over multiple instructions per 64 byte block.

[1] https://github.com/minio/sha256-simd/blob/master/sha256block... [2] https://software.intel.com/en-us/articles/intel-sha-extensio...

Interesting, thanks for pointing that out.

This code is such a good example of the potential value of formal verification tools for crypto primitives.

Reply on news.ycombinator.com