Maybe Skip SHA-3
imperialviolet.org
Maybe Skip SHA-3
1–10 of 188 posts
Re: Maybe Skip SHA-3
#2SHA-3 does seem to have relatively little to offer by way of incentives to switch. "Just as good" isn't motivation, and any notions of higher cryptographic strength haven't been extensively discussed. "Easier to implement in hardware" will be more compelling when such hardware exists.
I'm curious about the statement that SHA-3 is slow; it links to https://www.imperialviolet.org/2016/05/16/agility.html , which doesn't seem related, and matches the previous link. I wonder if that was supposed to link to somewhere else, like http://bench.cr.yp.to/results-sha3.html (as linked from https://www.imperialviolet.org/2012/10/21/nist.html )?
From that, SHA-3 certainly doesn't run significantly faster than alternatives (variants of BLAKE do indeed outperform it), but it seems roughly on par with SHA-256/SHA-512. But "on par" doesn't give any incentive to switch.
I wonder how much relative attention the SHA-3 winner (Keccak) gets compared to other alternatives, like BLAKE?
Re: Maybe Skip SHA-3
#3in short: "SHA-3 should probably not be used. It offers no compelling advantage over SHA-2 and brings many costs."
Re: Maybe Skip SHA-3
#4SHA-3 does seem to have relatively little to offer by way of incentives to switch. "Just as good" isn't motivation, and any notions of higher cryptographic strength haven't been extensively discussed. "Easier to implement in hardware" will be more compelling when such hardware exists. I'm curious about the statement that SHA-3 is slow; it links to https://www.imperialviolet.org/2016/05/16/agility.html , which doesn't…
Gah, thank you. I did, indeed, mean to link to bench.cr.yp.to. Fixed.
(The BLAKE2 page (https://blake2.net/) has a graph too.)
Re: Maybe Skip SHA-3
#5The 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.
Re: Maybe Skip SHA-3
#6> 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.
Re: Maybe Skip SHA-3
#7[deleted]
Re: Maybe Skip SHA-3
#8> 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?
Re: Maybe Skip SHA-3
#9> 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.
Re: Maybe Skip SHA-3
#10> 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?
An authenticated cipher is usually just a composition of a cipher and a MAC.