Hacker News new | ask | show | jobs
by kozak 3385 days ago
Do they anticipate that one day we'll have to move from SHA256 to something else again? It's only matter of time. Hash function have lifecycle. Tre transition has to be done in a way that will also make the next transition more straightforward.
2 comments

Reading even one changed line tells us that they replaced hardcoded char arrays for SHA1 with a generic struct that could be used as a container for any hash.

Some functions that previously operated on those char arrays have been changed to deal with the more generic struct instead.

I consider it unlikely that it will change again, but somehow it is unsatisfying that it doesn't have a hash version, e.g. in the first nibble of the hash. If they had done that we could have avoided the unpleasantness long ago.
A note on 'lifecycle': that's not how it works -- the age of use/lifecycle is not a function of the bit-length in hash, or inevitability of the current standard being broken.

Technically MD5(128bits) and SHA1(160bits) lengths are sufficient for hashes, but they had cryptographic weaknesses -- the functions had cryptanalytic attacks, which reduced bruteforce from the complete keyspace to something of a much smaller magnitude. These weaknesses are what has lead to the deprecation of MD5 and SHA1.

It is definitely possible that new crypt-analytic attacks could be shown on SHA256/512, but none have so far been publicly provided. Hence the confidence in them.

> Technically MD5(128bits) and SHA1(160bits) lengths are sufficient for hashes, but they had cryptographic weaknesses

Not true. A 128-bit hash gets collisions after ~2^64 tries. A big cluster can find targeted 128-bit collisions. To attack something like git, the entire attack can be done offline.

The big MD5 X.509 break needed cryptanalysis to make it day I because the attack needed to happen in real time.

The threat models in which 64 bits of security (by birthday attack on 128bit hashes) is insufficient are really limited.
That is misleading, since a birthday attack is not required. The security strength of hashes is not measured by the length of the hashes.

md5 was first "broken" in 1995. As of 10 years ago, a collision attack took only a few seconds. Plus, there are a _number_ of other attacks on the hash.

The argument I replied to concerned best-case for length. I.e. a perfect hash at 128 bits delivers 64 bits of security against collisions. (Note the 'perfect' part)

64 bits of security is good enough against most non-nation state actors.

Obviously, MD5 (and sha-1) aren't anywhere near perfect hashes. And obviously, you need to look at more than length when judging a hash.

Basically my point was that md5's hash length isn't a big problem.

You can rent Amazon time and create an md5 collision for less money than people spend going to a movie. Restating the issue as "a perfect hash is perfect" may be correct in a limited sense, but it is also highly misleading.

64 bits of ideal security is about half the industry accepted security strength in bits for a hash function.

The bitcoin network does 2^64 hashes in about 10 seconds. 10 seconds of bitcoin network is a far cry from nation state only.
For comparison, this is about the same level of cost as the recent collision attack on SHA-1. So even a perfect 128-bit hash is at least as broken as SHA-1 is.
On the other hand a hash function that works well in all scenarios that constitute a theoretically sound use of a cryptographic hash function is infinitely harder to misuse.
Yep, I'm not about the bit length: 256 bit "should be enough for everybody". But algorithms to generate those 256 bits will change.