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

31–40 of 112 posts

Re: Maybe we shouldn't skip SHA-3

#31

Post by yakult »

wybiral wrote: post #25
taneq wrote: post #23

Earlier quoted context omitted.

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.

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

Re: Maybe we shouldn't skip SHA-3

#32

Post by jfindley »

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…

To be fair, while I do agree with you, sha-2 512/256 is an especially confusingly named hash. A _lot_ of people naturally read it as sha-2 512 or 256, which it is not, but thing/otherthing is a common enough pattern that the confusion is understandable.

sha-2 256t or something would be much clearer. As the article notes, changing it now is not trivial, but given the potential for confusion is something that might be worth doing, none the less.

Re: Maybe we shouldn't skip SHA-3

#33

Post by kozak »

wybiral wrote: post #25
taneq wrote: post #23

Earlier quoted context omitted.

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.

Let's say I make a hash of an asset and put it into a very long-time archive (like 100 years or whatever). What checksum algorithm should I use to be sure it will be readily available in software after 100 years? And to make the choice more realistic, let's assume that the algorithm must be sufficiently fast today (like md5 is).

Re: Maybe we shouldn't skip SHA-3

#34

Post by tptacek »

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

> 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/KeccakT…

I don't think we're at any risk of research on hashing stopping.

Re: Maybe we shouldn't skip SHA-3

#35

Post by helthanatos »

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.

You should not use md5 for anything. It's completely broken and that's just asking for trouble if someone swaps out whatever your checksums are checking. It's worth the security to swallow the extra computational power. Though, if you're hosting something no one cares about, it's still worth the security to keep your small audience safe from the random malicious person you thought you'd never see.

Re: Maybe we shouldn't skip SHA-3

#36

Post by svenfaw »

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?

SHA256

Re: Maybe we shouldn't skip SHA-3

#37

Post by masklinn »

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…

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?

Re: Maybe we shouldn't skip SHA-3

#38

Post by kobeya »

nialo wrote: post #30
kobeya wrote: post #28

Earlier quoted context omitted.

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.

There are two forms of length extension, one where the attacker does know those bits. SHA-512/256 doesn't protect against that. (HMAC does, I believe.)

Re: Maybe we shouldn't skip SHA-3

#39

Post by tptacek »

masklinn wrote: post #37
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…

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.

Re: Maybe we shouldn't skip SHA-3

#40

Post by tptacek »

kobeya wrote: post #38
nialo wrote: post #30

Earlier quoted context omitted.

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.

There are two forms of length extension, one where the attacker does know those bits. SHA-512/256 doesn't protect against that. (HMAC does, I believe.)

No.
Post reply on HN