11–20 of 188 posts
Edit: Removed my comment regarding BLAKE as it was incorrect.
The SHAKE family of functions (and cryptographic sponges in general) are very cool, but like the article says, SHA-3 is weakened by failing to focus on performance. If SHA-2 is sufficiently secure (which looks more and more the case) then a faster SHA-2 would have been a better way of looking at what was wanted out of SHA-3. Faster primitives means more PBKDF rounds, more usage of hashes to secure underlying data.
Earlier quoted context omitted.
But aren't we trying to get away from MACs into authenticated ciphers?
An authenticated cipher is usually just a composition of a cipher and a MAC.
The assessment that SHA-3's performance is bad completely disregard the results from hardware benchmarking (FPGAs and ASICs). All the hardware results have shown conclusively that Keccak is multiple times faster than SHA-2. While I can't say that the algorithm is going to be supported in HW, with enough usage it might be the case. Edit: Removed my comment regarding BLAKE as it was incorrect.
Earlier quoted context omitted.
An authenticated cipher is usually just a composition of a cipher and a MAC.
That's historically true, but these days I think GCM is the most common. GCM also has hardware support from the CLMUL instruction set available on Intel processors since 2010 and AMD processors since 2011.
The assessment that SHA-3's performance is bad completely disregard the results from hardware benchmarking (FPGAs and ASICs). All the hardware results have shown conclusively that Keccak is multiple times faster than SHA-2. While I can't say that the algorithm is going to be supported in HW, with enough usage it might be the case. Edit: Removed my comment regarding BLAKE as it was incorrect.
ChaCha20, Poly1305, BLAKE2 benefit from improvements that benefit a wide-range of applications, while SHA-3, AES and GHASH do not. Thus the "cost" of high performance support for the former can be amortised over a much wider base.
> SHA-3 did introduce something useful To me the most useful part of SHA-3 is that you don't need to use HMAC as it is not vulnerable to length extension attacks. Meaning that it's much faster than SHA-2 when used as a MAC construction.
But aren't we trying to get away from MACs into authenticated ciphers?
The assessment that SHA-3's performance is bad completely disregard the results from hardware benchmarking (FPGAs and ASICs). All the hardware results have shown conclusively that Keccak is multiple times faster than SHA-2. While I can't say that the algorithm is going to be supported in HW, with enough usage it might be the case. Edit: Removed my comment regarding BLAKE as it was incorrect.
Isn't this something you don't want? I'd rather use an algo which is painful to do in bulk.
>[The diversity of cryptographic primitives] contributes to code-size, which is a worry again in the mobile age
In the "mobile age" we use embedded processors with gigabytes worth of RAM and several times the amount of NAND storage, I don't really think a SHA-3 implementation is going to tip the boat over.
The author's other points seem very fair though.
> SHA-3 did introduce something useful To me the most useful part of SHA-3 is that you don't need to use HMAC as it is not vulnerable to length extension attacks. Meaning that it's much faster than SHA-2 when used as a MAC construction.
That's a good point, but the truncated SHA-2 variants (512/224 and 512/256) are also not susceptible to length extension, and are faster than SHA-3. BLAKE2 was a SHA-3 finalist, and thus by definition isn't vulnerable to length extension either.
BLAKE2 wasn't, but BLAKE was.
Aside: Most people should continue to use HMAC-SHA256 instead of worrying about LEAs and justifying a switch to non-HMAC H(secret || message) constructions.