Maybe we shouldn't skip SHA-3

Post by tptacek » Fri, Jun 02, 2017, 1:36 PM UTC

baby wrote: post #7

tptacek wrote: post #2

If 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).

Post by JoachimS » Fri, Jun 02, 2017, 1:38 PM UTC

smitherfield wrote: post #5

nilved wrote: post #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. 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.

Post by tracked24x7 » Fri, Jun 02, 2017, 1:41 PM UTC

tptacek wrote: post #11

baby wrote: post #7

Earlier quoted context omitted.

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).

You keep saying that here, and on Twitter, and people --- not just me --- keep telling you that if you're going to recommend a hash specifically to avoid length extension attacks, 512/256 accomplishes that without requiring the adoption of new hashing code. I really don't understand the argument that people can safely type "SHA-3" but not "SHA-2 512/256". Would it help if we renamed SHA-2 512/256? We could call it SH…

Post by tptacek » Fri, Jun 02, 2017, 1:43 PM UTC

baby wrote: post #14

tptacek wrote: post #11

Earlier quoted context omitted.

You keep saying that here, and on Twitter, and people --- not just me --- keep telling you that if you're going to recommend a hash specifically to avoid length extension attacks, 512/256 accomplishes that without requiring the adoption of new hashing code. I really don't understand the argument that people can safely type "SHA-3" but not "SHA-2 512/256". Would it help if we renamed SHA-2 512/256? We could call it SH…

I addressed that point in the post. Unless you replace all the implementations of SHA-2, the deed is done. People will choose SHA-256 and SHA-512 because that's what they've always known. > without requiring the adoption of new hashing code I should have made myself clearer: I recommend SHA-3 for new projects. I wouldn't recommend people to switch to SHA-3 if they are already using SHA-2.

Post by tptacek » Fri, Jun 02, 2017, 1:44 PM UTC

nilved wrote: post #6

smitherfield wrote: post #5

Earlier quoted context omitted.

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.