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

81–90 of 112 posts

Re: Maybe we shouldn't skip SHA-3

#81

Post by dom0 »

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

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

The answer is that you don't want a hash, you want a solution that is ArchiSig or TR-ESOR (or something similar) compliant.

Re: Maybe we shouldn't skip SHA-3

#82

Post by dom0 »

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.

SHA-512/256 is a variant of SHA-512 where the output is truncated to 256 bits. It does not mean "SHA-512 or SHA-256". Yes, perhaps a different symbol than "/" would be better there.....

Re: Maybe we shouldn't skip SHA-3

#83

Post by dom0 »

tptacek wrote: post #69
Steeeve wrote: post #64

Earlier quoted context omitted.

> 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? The name is a serious problem. If you work with this stuff regularly enough to know the difference it might seem obvious, but that's not the case for many would-be implementors and bug-fixers. The name makes communication problematic enough to not recommend usage.

No, it doesn't. SHA-2 is by an overwhelming margin the most popular hash used in cryptosystems today, and it is overwhelmingly used safely. Seriously, if you care that much about the name, rename it; Even systems that use SHA-3 use HMAC (SHA-2 is perfectly safe, no matter what variant you use, in HMAC). Name the prefix MAC (an idiosyncratic construction) that uses SHA-2 something specific. The SHA-3 advocates have al…

I think the BLAKE2 authors just choose to call it "keyed hashing" and telling people to use it as a MAC. Only somewhere in the paper where the construction is described there is an embedded clause "yes yes, that's prefix mac, hush" :)

Re: Maybe we shouldn't skip SHA-3

#84

Post by dom0 »

baby wrote: post #47
tptacek wrote: post #17

Earlier quoted context omitted.

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.

> SHA-512/256 is a made-up algorithm

It's a published FIPS.

Re: Maybe we shouldn't skip SHA-3

#85

Post by dom0 »

bradleyjg wrote: post #54
StreamBright wrote: post #46

Earlier quoted context omitted.

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

If the application isn't security sensitive why not a faster non-cryptographic hash like farmhash?

These are often not packaged, so less available. Though for some applications you wouldn't want a library anyway.

(Also, xxhash)

Re: Maybe we shouldn't skip SHA-3

#86

Post by azinman2 »

cryptonector wrote: post #52
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?

Yes-ish. I don't sweat HMAC-MD5, nor HMAC-SHA-1. What really sucks though is when you can't use them (even though for interop reasons you must) because some stupid auditor (typically software) goes "oh no! MD5 found!! alert! alert!".

For us who don't know better, could you explain why MD5 or SHA1 are ok in an HMAC context?

Re: Maybe we shouldn't skip SHA-3

#87

Post by Steeeve »

tptacek wrote: post #69
Steeeve wrote: post #64

Earlier quoted context omitted.

> 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? The name is a serious problem. If you work with this stuff regularly enough to know the difference it might seem obvious, but that's not the case for many would-be implementors and bug-fixers. The name makes communication problematic enough to not recommend usage.

No, it doesn't. SHA-2 is by an overwhelming margin the most popular hash used in cryptosystems today, and it is overwhelmingly used safely. Seriously, if you care that much about the name, rename it; Even systems that use SHA-3 use HMAC (SHA-2 is perfectly safe, no matter what variant you use, in HMAC). Name the prefix MAC (an idiosyncratic construction) that uses SHA-2 something specific. The SHA-3 advocates have al…

Reading your post I find myself understanding what you are saying... maybe. And that's my point. Communication is unclear.

It's hard enough to follow this topic for many people that want to keep updated. The fact that you have to spell out "please use SHA2-512/256, but not SHA2-512 and not SHA2-256" is mind-numbing.

"It's really SHA2-512/t where t has a value of 256 and that means that it's SHA2-512 truncated down which alleviates length extension attacks." Just typing that sentence gave me a headache and I have no real idea if it's right or not.

Adoption would be easy if communication was easy. As it is, it's a PITA to even have a short conversation on the subject.

Re: Maybe we shouldn't skip SHA-3

#88

Post by espadrine »

dsacco wrote: post #71
espadrine wrote: post #26

Earlier quoted context omitted.

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

That's not necessarily a dangerous assertion. SHA-2 is theoretically immune to foreseeable improvements in computational power. If you use something like SHA-512, a birthday attack will require searching through approximately more candidates than there are atoms in the observable universe. You can't meaningfully improve this by scaling up inordinate amounts of computing power. If you can't rely on raw computational p…

> "improvements in math might happen" is not reliable enough to calibrate forced obsolescence or regular updates

Definitely: it doesn't make much sense to move away from a hash that doesn't seem in danger of being broken, just because it is old — a clever new attack can be found for a newer hash, too (or for both).

Besides, usually there's a lapse of time between finding a major weakness and a practical collision.

On the other hand, when picking a hash… well, having a faster and less error-prone hash is nice.

Overall, I feel lucky to have such great choice.

Re: Maybe we shouldn't skip SHA-3

#89

Post by apendleton »

dsacco wrote: post #71
espadrine wrote: post #26

Earlier quoted context omitted.

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

That's not necessarily a dangerous assertion. SHA-2 is theoretically immune to foreseeable improvements in computational power. If you use something like SHA-512, a birthday attack will require searching through approximately more candidates than there are atoms in the observable universe. You can't meaningfully improve this by scaling up inordinate amounts of computing power. If you can't rely on raw computational p…

Would it also be fair to say that novel math could just as easily be discovered that would break SHA-3, and so, switching to SHA-3 would not reduce risk? (Or, worse: might it increase it, since the SHA-3 constructions have been subject to less cryptographic research and so might be more likely to fall to some kind of new math?)

Re: Maybe we shouldn't skip SHA-3

#90

Post by tptacek »

Steeeve wrote: post #87
tptacek wrote: post #69

Earlier quoted context omitted.

No, it doesn't. SHA-2 is by an overwhelming margin the most popular hash used in cryptosystems today, and it is overwhelmingly used safely. Seriously, if you care that much about the name, rename it; Even systems that use SHA-3 use HMAC (SHA-2 is perfectly safe, no matter what variant you use, in HMAC). Name the prefix MAC (an idiosyncratic construction) that uses SHA-2 something specific. The SHA-3 advocates have al…

Reading your post I find myself understanding what you are saying... maybe. And that's my point. Communication is unclear. It's hard enough to follow this topic for many people that want to keep updated. The fact that you have to spell out "please use SHA2-512/256, but not SHA2-512 and not SHA2-256" is mind-numbing. "It's really SHA2-512/t where t has a value of 256 and that means that it's SHA2-512 truncated down wh…

I think you're confusing the SHA-2 hash core with a MAC derived from SHA-2. MACs and hashes aren't the same thing. You can build a MAC on a hash --- in fact, you can build a MAC on a hash that would be terribly insecure on its own, and some of those MACs are state-of-the art; see, for instance, all the polynomial MACs.

That's what I'm trying to articulate. Hashes aren't MACs.

This is partially my fault, for playing loose with SHA-2 512/256 vs "The Prefix MAC built on SHA-2 512/256".

Again: I think we should just call that SHA-2-MAC. It's an unambiguous name that couldn't mean anything other than "truncated SHA-2 512 used as a prefix MAC".

Post reply on HN