Guest post by On February 23rd, a joint team from the CWI Amsterdam and Google announced that they had generated the first ever collision in the SHA-1 cryptographic hashing algorithm. SHA-1 has long been considered theoretically insecure by cryptanalysts due to weaknesses in the algorithm design, but this marks the first time researchers were actually able to demonstrate a real-world example of the insecurity. In addition to being a powerful Proof of Concept (POC), the computing power that went into generating the proof was notable.
So what’s the big deal?
Unfortunately, the migration away from SHA-1 has not been universal. Some programs, such as the version control system Git, have SHA-1 hard-baked into its code. This makes it difficult for projects which rely on Git to ditch the algorithm altogether. The encrypted e-mail system PGP also relies on it in certain places.
Git has already patches to protect against collisions:
“the SHA1 routines that detect the attack are now in the ‘pu’ (proposed updates) branch of git, so you can just get that and then build with USE_SHA1DC:” (src: https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL)
Moreover, as Linus noted it is not a big deal for git, since SHA1 is used for object indexing not for real cryptography / encryption.
do not require SHA-1 at all. Any other checksum algorithm will do the job.
/pica
Still, you want a hash with a very, very low collision rate.
Anyway, all the messages “The end is coming!” is way overblown, as usual. People must keep in mind that hashes alone are never a proof, a guarantee of uniqueness and act accordingly.
yes, but a simple CRC-128 would be sufficient at least for my needs.
/pica
What need are yours, exactly? And why not a sha 2 or 3?
its not people I’m worried about, its existing programs and how they’ll deal with any collision.
https://arstechnica.com/security/2017/02/watershed-sha1-collision-ju…
GIT handles two files with equal hash as equal. Thats it.
/pica
/pica
Yes, git isn’t affected by the same bug in SVN. But how many other apps depend on sha1 uniqueness that can now be broken. People are somewhat more flexible and faster to update than software.
/metallophagia
To my understanding, the problem was two fold:
1) someone assuming that was safe to rely JUST on sha1 to detect duplication. That is not how hash algorithms work, period;
2) inserting files that can wreak havoc to repository BEFORE checking for collisions, inexcusable. (ï¼â€¸áƒš)
A good hash algorithm is a godsend to DCVS, like git, but it should not be that important to svn. People will fix the mistakes ASAP. On git case, it will probably need more safeguards and better handling. Collisions are already extremely rare and if you take into account that the “path + name” of files inside the repos guarantee uniqueness of location, it could be used, together with its size, to lower even more the collision probability and the handling of it.
I have two questions that I couldn’t find an answer anywhere:
1) Which version of SHA1 algorithm is compromised? How many bits?
2) Whitch algorithm to replace it? For instance SHA1 replaced MD5 for the same reason. Now which one?
A member of the SHA-2 family,SHA-256 is a commonly used hash algorithm. There is also the newer SHA-3 family, if your application supports it.
https://en.wikipedia.org/wiki/Secure_Hash_Algorithm