> 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...]
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.
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??
