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

41–50 of 112 posts

Re: Maybe we shouldn't skip SHA-3

#41

Post by snakeanus »

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.

What differences does K12 have compared to SHA-3? Just less rounds or are there more changes? Something similar to the differences between BLAKE and BLAKE2 maybe?

Re: Maybe we shouldn't skip SHA-3

#42

Post by snakeanus »

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

> (especially for tree hashing, which makes K12 better than any other hash to hash big files).

I am aware that other modern hash functions like BLAKE2 (and maybe BLAKE/Skein?) support tree hashing, is there any reason why K12 would be better for that?

Re: Maybe we shouldn't skip SHA-3

#43

Post by masklinn »

tptacek wrote: post #39
masklinn wrote: post #37

Earlier quoted context omitted.

Why not recommend SHA384 which AFAIK is exactly a truncated SHA512 without the "name collision" with SHA256? Or SHA224 which is the same from SHA256?

To maximize both performance and the number of truncated bits, which is the factor mitigating length extension.

> both performance

Surely SHA384 is no slower than SHA512/256 since both need to compute a SHA512 hash before truncation?

> and the number of truncated bits, which is the factor mitigating length extension.

Is there really a meaningful difference in mitigation between truncating 25% and 50% of the original hash?

Re: Maybe we shouldn't skip SHA-3

#44

Post by oconnor663 »

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?

BLAKE2 is faster than MD5. I think that means there's no longer any reason to use MD5 in new applications, if you have any choice.

Re: Maybe we shouldn't skip SHA-3

#45

Post by snakeanus »

yakult wrote: post #31
wybiral wrote: post #25

Earlier quoted context omitted.

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.

So what's the right algorithm to use instead of md5 if I just want a fast checksum that's widely supported?

BLAKE2b or BLAKE2bp should be a good choice for that. Or just CRC if you care only about unintentional changes.

Re: Maybe we shouldn't skip SHA-3

#46

Post by StreamBright »

tptacek wrote: post #22
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?

Definitely don't use MD5!

What if the use case is not security sensitive, I just want to implement a distributed hash ring for example?

Re: Maybe we shouldn't skip SHA-3

#47

Post by baby »

tptacek wrote: post #17
baby wrote: post #14

Earlier quoted context omitted.

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.

This is a little like saying that if you told someone to use Rijndael they might instead use DES.

I really don't agree. Rijndael and DES are different algorithm. SHA-512/256 is a made-up algorithm that you need to be aware of. Again I'm talking about "misuse" here. SHA-2 is vulnerable to misuse even if SHA-512/256 is not.

Re: Maybe we shouldn't skip SHA-3

#48

Post by baby »

snakeanus wrote: post #41
tptacek wrote: post #8

Earlier quoted context omitted.

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.

What differences does K12 have compared to SHA-3? Just less rounds or are there more changes? Something similar to the differences between BLAKE and BLAKE2 maybe?

It has half the rounds and a tree hashing mode by default, which makes it extremely fast when hashing big files (yes even in software). Check https://cryptologie.net/article/393/kangarootwelve/

Re: Maybe we shouldn't skip SHA-3

#49

Post by cryptonector »

So, AGL was speaking specifically about TLS. He wasn't suggesting other protocols / formats not use SHA-3 / SHAKE. But this blog post talks about misuse of hash functions as a reason to switch to SHA-3 as if AGL had not referred only to TLS.

That's a strawman. It's NOT useful.

EDIT: What's the one downvote for? Just curious!

Re: Maybe we shouldn't skip SHA-3

#50

Post by baby »

snakeanus wrote: post #42
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).

> (especially for tree hashing, which makes K12 better than any other hash to hash big files). I am aware that other modern hash functions like BLAKE2 (and maybe BLAKE/Skein?) support tree hashing, is there any reason why K12 would be better for that?

No not really. I cited BLAKE2bp or BLAKE2sp in the post.
Post reply on HN