4 ms·

I don't understand the practical attack vector for breaking SHA1s in Git. Not only are objects checksummed by SHA1, they also encode the length. Finding a SHA1

I don't understand the practical attack vector for breaking SHA1s in Git. Not only are objects checksummed by SHA1, they also encode the length. Finding a SHA1 collision is plausible, but finding a SHA1 collision that both lets you do something Nefarious, and is the length you need, seems really really unlikely

tialaramex 7y ago
This makes no sense. The collision manufacture algorithm of course produces the same length output in both the A and B documents. Doing otherwise would be considerably harder in fact.
HereBeBeasties 7y ago
You're assuming that 100% of the source code matters, but most source code has comments. Some has a lot of comments (boilerplate headers). Delete all the comments and superfluous whitespace, add nefarious code, put in a comment in the remaining bytes for the sole purpose of causing a hash collision (likely plenty of bytes to play with).
- scoutt 7y ago
  Yes, but... > this new version would have to contain the desired hostile code, still function as a working floppy driver, and not look like an obfuscated C code contest entry It's still plausible that one can pull a trick like that to introduce malicious code into the repo, but improbable.
est31 7y ago
The shattered collision attack featured two pdfs with the same sha1 and wait for it, the same length. Also note that even with normal sha1, the length is hashed into the final sha1 hash already, that's what the merkle damgard scheme is about. You can read about it on Wikipedia. Reusing the precise collision from the shattered attack is made impossible by initializing the state with anything other than the prefix from the shattered attack. But the cost for mounting such an attack yourself is only 11k USD. However, as git uses the sha1collisiondetection library, such an attack would be detected by current git. Thus, this library is a much better protection than the length encoding.
xxs 7y ago
Length actually is already part of the hash result... and the sha-1 collision uses the same length pdfs.
phaemon 7y ago
As mentioned, the shattered PDFs[1] have the same length, however it's worth noting that adding the Git header breaks the matching, ie. you get different SHA sums for the files in Git because of the header. [1] https://shattered.io/ https://shattered.io/
kzrdude 7y ago
SHA1 is crumbling. It's being replaced because it is likely to be broken further, in practice.
upofadown 7y ago
To make the collision work you need to produce two different files, both with some randomish looking junk in them. So if you can do that in a way where you can substitute one of the files for the other without getting caught then you are almost for sure smart enough to also figure out a way to make the lengths the same.
acidictadpole 7y ago
The author does seem to concede that hitting all the checkmarks in an attack on git would be pretty tricky: > An attacker would not just have to do that, though; this new version would have to contain the desired hostile code, still function as a working floppy driver, and not look like an obfuscated C code contest entry The whole idea is that they want to switch away before these things become likely. They are unlikely now, but SHA-1 is only getting weaker as time goes by and more research is done.
- pdonis 7y ago
  > and not look like an obfuscated C code contest entry The full quote here is even better: "and not look like an obfuscated C code contest entry (at least not more than it already does)."

tialaramex 7y ago

This makes no sense. The collision manufacture algorithm of course produces the same length output in both the A and B documents. Doing otherwise would be considerably harder in fact.

HereBeBeasties 7y ago

You're assuming that 100% of the source code matters, but most source code has comments. Some has a lot of comments (boilerplate headers). Delete all the comments and superfluous whitespace, add nefarious code, put in a comment in the remaining bytes for the sole purpose of causing a hash collision (likely plenty of bytes to play with).

scoutt 7y ago
Yes, but... > this new version would have to contain the desired hostile code, still function as a working floppy driver, and not look like an obfuscated C code contest entry It's still plausible that one can pull a trick like that to introduce malicious code into the repo, but improbable.

est31 7y ago

The shattered collision attack featured two pdfs with the same sha1 and wait for it, the same length. Also note that even with normal sha1, the length is hashed into the final sha1 hash already, that's what the merkle damgard scheme is about. You can read about it on Wikipedia. Reusing the precise collision from the shattered attack is made impossible by initializing the state with anything other than the prefix from the shattered attack. But the cost for mounting such an attack yourself is only 11k USD. However, as git uses the sha1collisiondetection library, such an attack would be detected by current git. Thus, this library is a much better protection than the length encoding.

xxs 7y ago

Length actually is already part of the hash result... and the sha-1 collision uses the same length pdfs.

phaemon 7y ago

As mentioned, the shattered PDFs[1] have the same length, however it's worth noting that adding the Git header breaks the matching, ie. you get different SHA sums for the files in Git because of the header. [1] https://shattered.io/ https://shattered.io/

kzrdude 7y ago

SHA1 is crumbling. It's being replaced because it is likely to be broken further, in practice.

upofadown 7y ago

To make the collision work you need to produce two different files, both with some randomish looking junk in them. So if you can do that in a way where you can substitute one of the files for the other without getting caught then you are almost for sure smart enough to also figure out a way to make the lengths the same.

acidictadpole 7y ago

The author does seem to concede that hitting all the checkmarks in an attack on git would be pretty tricky: > An attacker would not just have to do that, though; this new version would have to contain the desired hostile code, still function as a working floppy driver, and not look like an obfuscated C code contest entry The whole idea is that they want to switch away before these things become likely. They are unlikely now, but SHA-1 is only getting weaker as time goes by and more research is done.

pdonis 7y ago
> and not look like an obfuscated C code contest entry The full quote here is even better: "and not look like an obfuscated C code contest entry (at least not more than it already does)."