[pawadu]

Here is my problem with this statement: SHA-1 can be used in different configurations for different applications. Some are secure, some are not.

People making these blanket statement very clearly demonstrate that they don't understand security and cryptography. Do you really want to use a security tool written by such people?

https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

[CJefferson]

I disagree with Linus here -- there are hashes which are secure in all ways, and hashes which are broken, like SHA1. Why try to figure out where SHA1 is safe?

Also, git's use of SHA1 is completely broken, it's just that no-one (that we know of) has chosen to spend the money required to make evil git repositories (you can't just take existing collisions and use them in git, you would have to go find git-specific ones).

[breser]

You'd have to find collisions that are of an identical length and still be useful (i.e. able to do something evil rather than just being a bunch of random data). The current techniques for creating collisions in SHA1 don't make it possible to find identical length collisions. So your statement that nobody has bothered to spend the money to create the collisions is not correct.

Now if you want to say that nobody has spent the time to find a technique to produce identically sized collisions, that would be correct. But that's far from trivial and we don't know that such a technique is guaranteed to exist.

[CJefferson]

I think you are behind the times. There is already pairs of identical SHA1s, that do "interesting things", like these two PDFs by Google (and others): http://shattered.io/. Both 422435 bytes.

[0x6c6f6c]

Or you aren't understanding the key statement of his comment

> You'd have to find collisions that are of an identical length and still be useful

Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible.

Git doesn't simply SHA-1 a file or the repo, it's more than that.

Linus:

> I haven't seen the attack yet, but git doesn't actually just hash the data, it does prepend a type/length field to it. That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header.

[https://stackoverflow.com/questions/42433126/how-does-the-ne...]

[deathanatos]

> Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible.

This is incorrect. Git attaches a header to the blob before hashing, that much is true, but the technique used by Shattered to create colliding hashes can be used to create colliding Git hashes as well — you simply need to take the header into account in advance of doing the collision. (Which is why the particular PDF files released by Shattered do not hash to the same value in Git, but that does not mean that the technique used does not apply: it does.) At the time of shattered's release, I commented on this[1]; that comment goes a bit more into the paper's findings.

> Or you aren't understanding the key statement of his comment

Frankly, I thought the key statement of his original comment, as applicable to SSH, was, why use SHA1 when SHA256 exists, and doesn't have these issues? Take the route that requires you to not need to be a cryptographer to figure out if it'll work or not.

[1]: https://news.ycombinator.com/item?id=13729985

[bobsam]

> Or you aren't understanding the key statement of his comment

Sounds like it. People STOP referring to shattered.io, it is an entirely different issue.

Also, even if this was related... Can you really use shattered for MITM during key exchange which takes fraction of a second when that attack takes weeks of computation on a cluster of supercomputers??