Maybe we shouldn't skip SHA-3
cryptologie.net
Maybe we shouldn't skip SHA-3
1–10 of 112 posts
Re: Maybe we shouldn't skip SHA-3
#2If you're going to pick a hash specifically to avoid length-extension attacks, pick SHA-2 512/256, which isn't vulnerable to length extension attacks. Or, for that matter, pick Blake2, which is a slightly less idiosyncratic choice than SHA-3. Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance.
SHA-2 512/256 is much faster than SHA-3 and supported by more libraries.
The notion that by recommending SHA-2 512/256 you're setting people up to use prefix MAC SHA-2 512 or SHA-2 256 is kind of silly. You could similarly argue that by telling people to use SHA-3, you're risking that they "fall back" to SHA-2. Either way, you're calling for a specific hash.
The reality is that some people like SHA-3 because it's interesting and because its primitives can be used for a variety of non-hashing applications. That's true! Nobody is saying SHA-3 shouldn't exist. They're just saying: there's no good reason to use it in a modern application.
(If you're not clear on length-extension attacks: they're the reason we use HMAC. HMAC-SHA2 isn't vulnerable to length extension attacks; neither is HMAC-SHA1 or HMAC-MD5 --- both of which, fun fact, can't currently be attacked, despite the weakness of their underlying hash. But if you use SHA-2 512/256, you don't have to use HMAC.)
Re: Maybe we shouldn't skip SHA-3
#3> The reality is that you should use SHA-3. I'm making this as a broad recommendation for people who do not know much about cryptography. You can't go wrong with the NIST's standard.
Re: Maybe we shouldn't skip SHA-3
#4If you're going to pick a hash specifically to avoid length-extension attacks, pick SHA-2 512/256, which isn't vulnerable to length extension attacks. Or, for that matter, pick Blake2, which is a slightly less idiosyncratic choice than SHA-3. Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance. SHA-2 512/256 is much faster than SHA-3 and supported by more lib…
> Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance.
Would another variant of Keccak, not the one that became SHA-3, provide more competitive results? Or does Keccak in general not have compelling properties compared to the alternatives?
Re: Maybe we shouldn't skip SHA-3
#5> The reality is that you should use SHA-3. I'm making this as a broad recommendation for people who do not know much about cryptography. You can't go wrong with the NIST's standard. https://en.wikipedia.org/wiki/Dual_EC_DRBG
If your claim is that SHA-3 contains an NSA backdoor, that's an extraordinary claim requiring extraordinary evidence.[1] In the case you link to, the NSA was publicly the author and the backdoor was "obvious" nearly from the start.
[1] Or else a conspiracy theory. Not that conspiracy theories are never true; I'd be surprised but not shocked if this one were.
Re: Maybe we shouldn't skip SHA-3
#6> The reality is that you should use SHA-3. I'm making this as a broad recommendation for people who do not know much about cryptography. You can't go wrong with the NIST's standard. https://en.wikipedia.org/wiki/Dual_EC_DRBG
If your claim is that SHA-3 contains an NSA backdoor, that's an extraordinary claim requiring extraordinary evidence.[1] In the case you link to, the NSA was publicly the author and the backdoor was "obvious" nearly from the start. [1] Or else a conspiracy theory. Not that conspiracy theories are never true; I'd be surprised but not shocked if this one were.
No, my claim is simply that NIST sponsorship is not a good reason to use it.
Re: Maybe we shouldn't skip SHA-3
#7If you're going to pick a hash specifically to avoid length-extension attacks, pick SHA-2 512/256, which isn't vulnerable to length extension attacks. Or, for that matter, pick Blake2, which is a slightly less idiosyncratic choice than SHA-3. Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance. SHA-2 512/256 is much faster than SHA-3 and supported by more lib…
I think our comments and discussions just add to the general confusion though, this is why I just plainly recommend SHA-3.
Now if I would personally work on a project I would think of SHAKE first, and I would seriously consider KangarooTwelve (especially for tree hashing, which makes K12 better than any other hash to hash big files).
Re: Maybe we shouldn't skip SHA-3
#8If you're going to pick a hash specifically to avoid length-extension attacks, pick SHA-2 512/256, which isn't vulnerable to length extension attacks. Or, for that matter, pick Blake2, which is a slightly less idiosyncratic choice than SHA-3. Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance. SHA-2 512/256 is much faster than SHA-3 and supported by more lib…
> Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance. Would another variant of Keccak, not the one that became SHA-3, provide more competitive results? Or does Keccak in general not have compelling properties compared to the alternatives?
Yes, there is one: KangarooTwelve, by the Keccak authors.
The problem is, there's just not a lot of reasons to use it. SHA-2 isn't broken; in fact, there are hash cryptographers who think SHA-2 may never be broken.
Re: Maybe we shouldn't skip SHA-3
#9> The reality is that you should use SHA-3. I'm making this as a broad recommendation for people who do not know much about cryptography. You can't go wrong with the NIST's standard. https://en.wikipedia.org/wiki/Dual_EC_DRBG
Oh yeah I should rephrase that :D
Re: Maybe we shouldn't skip SHA-3
#10If you're going to pick a hash specifically to avoid length-extension attacks, pick SHA-2 512/256, which isn't vulnerable to length extension attacks. Or, for that matter, pick Blake2, which is a slightly less idiosyncratic choice than SHA-3. Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance. SHA-2 512/256 is much faster than SHA-3 and supported by more lib…
> Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance. Would another variant of Keccak, not the one that became SHA-3, provide more competitive results? Or does Keccak in general not have compelling properties compared to the alternatives?
The parameters NIST specified are just fairly conservative, for one thing (e.g. NIST, IIRC, oddly requested an increase in the number of rounds during the final stages, one of the things people waxed on about.)
Regarding another variant: yes, you can get more compelling results, and the authors of Keccak themselves have also proposed another function based on Keccak called KangarooTwelve[1]. K12 has much better performance and parallelism than SHA-3 does in software. (Of course, if you don't need most of Keccak's general properties, you're probably fine with other hashes anyway.)