Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe we shouldn't skip SHA-3

cryptologie.net

Post reply on HN
Print view View original

21–30 of 112 posts

Re: Maybe we shouldn't skip SHA-3

#21

Post by baby »

JoachimS wrote: post #18
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…

Regarding MD5. I advice people from using MD5 in new designs even if it is for HMAC-MD5. Not because that construct is broken (which it isn't), but because we add yet another dependency on an algorithm we in general consider too weak to use. Do you agreee with that advice?

Yeah, that's a good argument to move to a stronger hash function for HMAC.

Re: Maybe we shouldn't skip SHA-3

#22

Post by tptacek »

JoachimS wrote: post #18
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…

Regarding MD5. I advice people from using MD5 in new designs even if it is for HMAC-MD5. Not because that construct is broken (which it isn't), but because we add yet another dependency on an algorithm we in general consider too weak to use. Do you agreee with that advice?

Definitely don't use MD5!

Re: Maybe we shouldn't skip SHA-3

#23

Post by taneq »

JoachimS wrote: post #18
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…

Regarding MD5. I advice people from using MD5 in new designs even if it is for HMAC-MD5. Not because that construct is broken (which it isn't), but because we add yet another dependency on an algorithm we in general consider too weak to use. Do you agreee with that advice?

It depends what you're using it for, no?

If you're using it as part of an auth mechanism then sure, don't use it. If you're using it for anything else (checksum, verification etc.) where you don't expect any adversarial action then it's fine.

Re: Maybe we shouldn't skip SHA-3

#24

Post by johnhenry »

We can look at technologies from two different points of view -- a engineers or as scientists. As engineers, we look at sha-3 as a practical means to an end -- just a secure hashing algorithm. From that point of view, its un-necessary as we already have sha-2. As scientists, it's an experiment and we're still waiting to see the results. The hypothesis is that its existence will strengthen our existing pool of hashing algorithms. We should note that this is a poor hypothesis; given that we don't see any flaws in our [only?] other algorithm, it's currently impossible to test. However; as with many other important experiments, we are seeing other un-expected results and applications. As an engineer, I acknowledge that it's probably best to skip it in most production applications. But as a scientist, let's not skip if anything cool happens down the line?

Re: Maybe we shouldn't skip SHA-3

#25

Post by wybiral »

taneq wrote: post #23
JoachimS wrote: post #18

Earlier quoted context omitted.

Regarding MD5. I advice people from using MD5 in new designs even if it is for HMAC-MD5. Not because that construct is broken (which it isn't), but because we add yet another dependency on an algorithm we in general consider too weak to use. Do you agreee with that advice?

It depends what you're using it for, no? If you're using it as part of an auth mechanism then sure, don't use it. If you're using it for anything else (checksum, verification etc.) where you don't expect any adversarial action then it's fine.

I think the point they were making was that since we know of weaknesses in certain situations we should avoid using it even in the safe situations so that we can eventually drop it from crypto libraries all together. There are alternatives that we can all move to.

Re: Maybe we shouldn't skip SHA-3

#26

Post by espadrine »

tptacek wrote: post #8
JoshTriplett wrote: post #4

Earlier quoted context omitted.

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

> there are hash cryptographers who think SHA-2 may never be broken.

It is a dangerous assertion, especially if it makes people build things that aren't future-proof enough to support more than one hash type.

Otherwise, KangarooTwelve is faster than SHA-2[0], which may be an incentive. Although it is very late compared to BLAKE2, and as a result, it is present in much fewer libraries.

[0]: https://twitter.com/KeccakTeam/status/834789451708628995

Re: Maybe we shouldn't skip SHA-3

#27

Post by sp332 »

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…

We should definitely rename it, because until yesterday I didn't know that "SHA-512/256" was an actual thing. I thought it was just shorthand referring to both SHA-512 and SHA-256.

Edit: this comment got 7 upvotes before the editing timeout, so I'm not the only one either.

Re: Maybe we shouldn't skip SHA-3

#28

Post by kobeya »

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…

How is SHA-512/256 not vulnerable to length extension attacks? I've implemented the SHA family of hash functions before and the only real difference between the two is block size and truncation of output, but I don't see how that stops length extensions.

Re: Maybe we shouldn't skip SHA-3

#29

Post by helper »

kobeya wrote: post #28
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…

How is SHA-512/256 not vulnerable to length extension attacks? I've implemented the SHA family of hash functions before and the only real difference between the two is block size and truncation of output, but I don't see how that stops length extensions.

You can't add more data once you've truncated.

Re: Maybe we shouldn't skip SHA-3

#30

Post by nialo »

kobeya wrote: post #28
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…

How is SHA-512/256 not vulnerable to length extension attacks? I've implemented the SHA family of hash functions before and the only real difference between the two is block size and truncation of output, but I don't see how that stops length extensions.

Have you tried implementing the length extension attacks?

Truncating from 512 bits to 256 bits hides 256 bits of the state from the attacker, so in order to use a length extension attack they would need to "guess" those bits.

Post reply on HN