Re:Linus' reply on Git and SHA-1 collision
by Perseids on Friday February 24, 2017 @04:21AM
(#13722225)
> Wow, Linus raises an entirely different issue which is that the PDF-based attack can't and won't work on git at all. Due to length prefixing it is extremely difficult to insert some nonsense into the middle of a git object which is how this attack works on PDFs.
Please note that the shattered-{1,2}.pdf files both have exactly the same length. And even with cleartext it is easy to pad passages so they contain the same amount of bytes. See how the quoted paragraph above has exactly the same number of characters as this one.
Re:Linus' reply on Git and SHA-1 collision
by throwmenow_0140 on Friday February 24, 2017 @05:38AM
(#13722529)
>>> len('''> Wow, Linus raises an entirely different issue which is that the PDF-based attack can't and won't work on git at all. Due to length prefixing it is extremely difficult to insert some nonsense into the middle of a git object which is how this attack works on PDFs.''')
264
>>> len('''Please note that the shattered-{1,2}.pdf files both have exactly the same length. And even with cleartext it is easy to pad passages so they contain the same amount of bytes. See how the quoted paragraph above has exactly the same number of characters as this one.''')
264
Re:Linus' reply on Git and SHA-1 collision
by makomk on Friday February 24, 2017 @06:36AM
(#13722740)
Indeed, they probably have to have the same length since the length is inserted into the final block as part of SHA-1 hashing and every block after the collision must be the same. I don't think it's even possible to create a MD5 collision between two documents of different length yet.
Re:Linus' reply on Git and SHA-1 collision
by yellowapple on Friday February 24, 2017 @06:08AM
(#13722638)
I'd be more impressed if both paragraphs also had the same SHA-1 hash ;)
Re:Linus' reply on Git and SHA-1 collision
by brillyfresh on Friday February 24, 2017 @09:23AM
(#13723847)
What if the hash of the second paragraph had exactly the same number of characters as the hash of the first one? ;)
1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust.
I don't think I've ever (intentionally) used git over HTTPS. I always clone using ssh (which has its own authentication mechanisms) or the git protocol (which is read-only).
2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage attack costs 2^(2n).
Thankfully, the collision attack doesn't apply to git (see above) so the cost ought to be greater than 2^n for a collision.
3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's objects, they'd still have to convince you pull from their repo. This requires trust.
Find a popular git host (say, Github but if a popular project is on Git Lab or Bitbucket, they will do just as well) and compromise them. Target a recent release for a popular project (say, Rails) and poison a relevant object that gets pulled down by all the downstream maintainers to package the release.
The benefit to straight up compromising a git repo without faking the hash lies in introducing a vulnerability without the maintainers nor developers of the project noticing (or noticing months/years after the fact).