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

71–80 of 112 posts

Re: Maybe we shouldn't skip SHA-3

#71

Post by dsacco »

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…

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 power to force obsolescence, you need either a major paradigm shift (a la quantum computing) or a clever cryptanalytic attack that bypasses the actual difficulty.

Quantum computers do not currently pose a serious threat to SHA-2. Grover's algorithm can offer a quadratic improvement to collision identification, but not an exponential one. That's impressive, but not enough on its own.

That leaves the last category, which is a clever cryptanalytic attack. This is possible, especially with novel mathematics. But it's not reliable for predicting risk.

So really, the only "future-proofing" we can do for SHA-2 is against vague improvements in the underlying math. In any practical sense of the term, it's not a dangerous assertion to claim SHA-2 may never be broken. As Thomas said, research will certainly continue on cryptographic hash functions regardless; moreover, "improvements in math might happen" is not reliable enough to calibrate forced obsolescence or regular updates to hash standards in the future.

Given the foregoing, some researchers choose to act as though SHA-2 will never be broken, because there's no meaningful way to assert that it probably will or to coordinate when or how it will, and because there are so many more productive areas of research to focus on where the current algorithms absolutely will be broken in the future. You can't productively work on future-proofing something any further once the space of coherent threats has been reduced to, "this might happen in the future somehow" without real specifics.

Re: Maybe we shouldn't skip SHA-3

#72

Post by tptacek »

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…

Additionally, the primitives used in the SHA-2 core are well-enough understood and accepted that for SHA-2 to be broken, pretty much all the hashes are going to end up broken --- is how the rest of the logic would go.

(This is, I think, JP Aumasson's argument.)

Re: Maybe we shouldn't skip SHA-3

#73

Post by baby »

remcob wrote: post #57

In which use cases is the asymptotic cycles per byte relevant compared to the small case performance? I mostly use hashes as part of signing/verifying small messages, say an 80 byte JWT, a Blockchain transaction, a certificate, an TLS/SSH packet, etc. Besides hashing large files (which I rarely do), I don't see where I would reach asymptotic performance, or even use tree-hashing. SHA3's block size is 200 bytes, Kanga…

> I mostly use hashes as part of signing/verifying small messages, say an 80 byte JWT, a Blockchain transaction, a certificate, an TLS/SSH packet, etc. Besides hashing large files (which I rarely do), I don't see where I would reach asymptotic performance, or even use tree-hashing.

The number I used is definitely not the best one. But I believe it applies to you as you're not hashing a lot of bytes so you will not see much of a speed difference between hash functions.

> SHA3's block size is 200 bytes, KangarooTwelve's is, if I'm not mistaken, 8192? I'm more worried about not even filling the first block :)

They have the same block size :o rather 8192 is the threshold before you start using the tree hashing mode. This way if you want to hash small messages you do not get a penalty from using KangarooTwelve! It's all good :)

Re: Maybe we shouldn't skip SHA-3

#74

Post by dsacco »

tptacek wrote: post #72
dsacco wrote: post #71

Earlier quoted context omitted.

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…

Additionally, the primitives used in the SHA-2 core are well-enough understood and accepted that for SHA-2 to be broken, pretty much all the hashes are going to end up broken --- is how the rest of the logic would go. (This is, I think, JP Aumasson's argument.)

Yeah, that's Aumasson. He compared it to finding that P=NP; sure it could happen, but it probably won't, and by the time we get that far "future-proofing" suddenly ceases to be a coherent concept for a lot more than just SHA-2.

Re: Maybe we shouldn't skip SHA-3

#75

Post by [deleted] »

cryptonector wrote: post #49

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!

[deleted]

Re: Maybe we shouldn't skip SHA-3

#76

Post by dom0 »

oconnor663 wrote: post #44
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?

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.

While the portable, pure C implementation of BLAKE2 that is used almost exclusively by libraries (e.g. Python, OpenSSL) is already faster than MD5...

...there are even faster implementations of BLAKE2 around. E.g. Samuel Neves' AVX2 implementation is almost 40 % faster on Haswell. libsodium ships a different AVX2 implementation (considered experimental AFAIK by its original author, so I find that a bit strange).

Re: Maybe we shouldn't skip SHA-3

#77

Post by dom0 »

jfindley wrote: post #32
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…

I've seen it written as "SHA-2 512-256", which is a bit less confusing.

Re: Maybe we shouldn't skip SHA-3

#78

Post by ben0x539 »

btrask wrote: post #62
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 use case isn't security critical, and you know for a fact it won't become security critical later, and MD5 is convenient for whatever reason, then just use MD5. Pardon my frustration, but: Jesus Christ, people. Why do we need to sell everyone on the fancy new thing in a hypothetical situation where it is defined not to matter?

Because now people are carrying an MD5 implementation around with them, and when the next vaguely-hash-shaped problem comes up, they're gonna reach for that without really evaluating, b/c they've used it before so and it's at the top of their mental cache and it's even more convenient now. :/

I guess it's not entirely equivalent but I'm still sorta reeling from a "why should we introduce [something like bcrypt] for password storage when we already have these other perfectly fine hash functions in use in our codebase" convo at a previous project.

Re: Maybe we shouldn't skip SHA-3

#79

Post by dom0 »

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'm not that sure about that. In the history of cryptography almost everything was broken in the end (though some peculiar stuff took a couple hundred years), but it seems that with modern cryptography, which is very, very different from classic cryptography, breaking it is far more difficult, and the intervals at which algorithms fall apart seem to increase.

For example, DES held out for about 20-25 years or so, with some cracks showing earlier than that. AES is now ~20 years old, and we don't have a discovered a single crack in it. SHA-2 is a similar vintage and no significant issues have been discovered. The previous generation of hashes only resisted ten years or so until the first real issues showed up.

Post reply on HN