Re:The first chosen-prefix collision for SHA-1
by rkangel on Tuesday January 07, 2020 @09:25AM
(#21980136)
If you look in this 2017 (https://marc.info/?l=git&m=148787047422954) email from Linux, he discusses how git also encodes length. That would mean that you need a collision of the same length and the right functionality, so you can't just append data.
I’m gonna say many developers will not care but and many compilers will not care either.
So yeah, Linus’ main deterrent reason (code won’t compile) doesn’t apply anymore.
HOWEVER!
1. A chosen-prefix attack still needs to compute TWO suffixes m1 and m2 so that h(a1+m1) = h(a2+m2). This does NOT mean that given a1 and a2 you can find a single m2 so that h(a1) = h(a2+m2). So that ONLY THE ORIGINAL AUTHOR OF THE COMMIT could spoof their own commit, by preparing in advance and attaching a long and weird comment in the end. And you could build tools to watch out for such commits in the first place
2. If git had used HMAC based on SHA1 then it would have been fine, even after this attack has become feasible.
3. Furthermore, it is likely still kinda fine because Merkle Trees have nodes referencing previous nodes. You’d have to spoof every historical node as well, to push malicious code. BitTorrent also requires computers to supply an entire merkle branch when serving file chunks.
Maybe someone can elaborate on this.