Rant: Keccak, or the case for software-first ciphers
This is a short rant on SHA3/Keccak which I have some non-security-related issues with
i’m once again slightly annoyed that keccak won sha3
it’s a hash algorithm that clearly favors hw implementations — that still are not widely deployed almost a decade after the release of the sha3 publication — and i think that hampers adoption a bit
in the adoption phase ~all deployments are going to use software implementations of cryptographic primitives, as it is much slower to deploy hardware implementations (see above)
while it doesn’t provide any protection against length extension attacks, sha2 is not known to be broken in other ways. It is still widely secure if length extension attacks don’t apply or you perform adequate mitigations for the issue[1]. I am also not sure if the authors of SHA2 could have anticipated length extension attacks.
Due to this there isn’t a particular pressure to adopt sha3. On the other hand the performance does speak for itself. On my ryzen 7700X and my core i5-7300U with tested with openssl speed:
Algorithm | Ryzen 7-7700X | Core i5-7300U | relative |
---|---|---|---|
sha512 | ~1.3GB/s | ~656MB/s | 100% |
sha3-512 | ~400MB/s | ~198MB/s | 30% |
blake2b512 | ~1.5GB/s | ~799MB/s | 115% |
I ran them on both machines because the Ryzen 7700X has support for AVX512 instructions, which may speed up sha3 and blake2b in a way unrepresentative of “typical” PCs. This didn’t appear to make a difference. My guess is that AVX512 support just isn’t enabled in my copy of openssl, or that the speed gains from AVX512 were almost entirely negated by the 256 bit vector path inside of the CPU.
sha512 uses hardware acceleration to achieve these speeds, as in the 20+ years since sha2’s release, sha2 acceleration has become widely available.
I think that the comparatively slow speed of sha3 in real world implementations, combined with the only modest amount of security improvements, makes a poor case for upgrading. This lack of adoption also means that hardware implementations are less likely to be deployed, since there is no reason to spend silicon area on a cryptographic algorithm that is only occasionally used. This might be changing in the future as more cryptographic protocols and primitives are built on top of it, however (like SLH-DSA).
In order for more secure algorithms to proliferate, I believe that the security benefit needs to be significant, or the speed/usability loss be kept low. sha3 does not meet this bar yet (this is going to change!), while blake2 and especially blake3 have met it from day 1.
This isn’t commentary about the relative security levels of the 3 algorithms, but I believe that even the most cryptographically sound algorithm is not particularly useful if it is not used in practice due to usability issues.
This rant shouldn’t dissuade you from using SHA-3. It is a safe choice and a cryptographer could tell you why. I’m just annoyed at the selection of the winner for the SHA3 competition.
- 1.Such measures include truncating the hash, using SHA2-384, canonicalization [i.e. prepending a constant-width length], and maybe also double-hashing? ↩