12 ms·
Lifetimes of cryptographic hash functions
- mtgx 10y agoIf you're not willing to move to SHA256 "because of performance," you should at least move to Blake2. https://blake2.net/ https://blake2.net/ There's no excuse for staying with SHA1 at this point.
- thunderbong 10y agoFrom the article - [3] Google spent 6500 CPU years and 110 GPU years to convince everyone we need to stop using SHA-1 for security critical applications
- ben_w 10y agoAnd the next fifteen years of Moore's Law will take that down to, what, 1 GPU month even without further algorithmic improvements? Which are anticipated? I still see things that use 2-digit years, twenty years after the last millennium bug should have been fixed.
- username223 10y ago"Next fifteen years of Moore's Law?" The recent failure of Intel's "tick-tock" alternation of process shrinkage and new architecture suggests that however performance improves in the next 15 years, projecting the last 15 years' Moore's Law forward is a bad idea. For crypto stuff, I'd think about how quantum computing may advance by the 2030s.
- jdavis703 10y agoNot only that, but it's better to start planning for a post SHA-1 reality before there's a real fire drill.
- r1ch 10y agoUnless my math is off, the combined power of the bitcoin network could find collisions in seconds (ignoring SHA-1 vs SHA-256). It isn't too unreasonable to assume that kind of hardware power would be available to nation states.
- hsivonen 10y agoIndeed, it would be nice if the article acknowledged the existence of BLAKE2b.
- bjornsing 10y ago> Non-expert ("slashdotter") reaction: > Explain why a simple collision attack is still useless, it's really the second pre-image attack that counts Why is this the "non-expert reaction?" It's correct, right? And why go to the trouble of making a timeline with "Broken" and "Collision found" without a "Second pre-image found"? I'm genuinely puzzled (and have asked it here on HN before [1]), but I unfortunately suspect that an honest answer lies somewhere along these lines: "Second pre-images are a hell of lot more difficult to find than collisions, so if we waited around for a second pre-image to be found we'd never get to dance around like headless chickens and talk about really scary shit (which typically requires a second pre-image) as 'now practical'. That would make the whole field a lot less sexy, and cut into our 'expert' consulting fees..." 1. https://news.ycombinator.com/item?id=13729492 https://news.ycombinator.com/item?id=13729492 EDIT: I'm of course not advocating staying with SHA-1. There's absolutely no good reason to. Even years ago when I was last involved in choosing a cryptographic hash function (even truncated) SHA-256 was obviously a much better choice.
- stestagg 10y agoI had a similar thought, but actually prefer this way. People who understand things well enough will know what first collision means, so can moderate their response. Others who are less familiar with the ridiculous levels of subtlety around this sort of thing are better off being given the simple message that sha1 is now legacy in all cases. Helps to avoid mistakes.
- bjornsing 10y agoSimple "truths" are sometimes useful. I can see that. I'm more surprised though at the resentful attitude towards the actual truth (in the non-alternative sense): collisions are useless in many cases and the necessary second pre-image is much more difficult to find. At least in a forum like HN I'd expect intellectual honesty to prevail. EDIT: Removed the incorrect example out of pure shame! :P
- detaro 10y ago/u/pvg linked below how the ability to generate collisions for MD5 was used to obtain a fake CA certificate. It's not obvious to me that this would not work with SHA-1 certificates, and that no other important things we use have similar weaknesses. (Neither do I know for sure that it would work, but "collisions are useless" seems like a dangerous simplification in the other direction. I suspect for many, simply replacing SHA-1 with something deemed better is easier than thoroughly evaluating the risks involved with not doing so)
- Kametrixom 10y agoFor anyone needing to decide what hash function to use, I recommend to have a look at multihash: https://github.com/multiformats/multihash https://github.com/multiformats/multihash
- kobeya 10y agoThe SHA-256 "weakness" is a bit disingenuous. As far as I'm aware in the 10 years since that paper was published the "weakness" hasn't been extended _at all_. The main reason for the SHA3 competition was because we were all concerned at the time that SHA2 would be broken and there'd be nothing to replace it with. However as it happens, SHA2 has remained rock solid, so the outcome of SHA3 was to pick something (Keccak) maximally different from SHA2, since in the intervening years cryptographic diversity became more desired than actual replacement. Both SHA2 and SHA3 are fit for use in production systems -- I would personally pick SHA2 unless I had some specific reason to benefit from SHA3 (e.g. incremental hashing modes that the sponge construction makes possible).
- kzrdude 10y agoIt looks like it's important to switch to a variant of SHA-2 that is truncated (like SHA-384 or SHA-512/256 for example), since they are more robust. No trivial length extension attack since they don't put the whole internal state in the output. This would be if one cares about how violently you fall if SHA-2 is broken more, but I think you should care.
- nayuki 10y agoWhat is the status of the Whirlpool hash function? Can it be added to the color table?