5 ms·
This is not a pre-image attack, so you can't create a file that matches an existing SHA1. It's a collision attack, so you can create two files whose SHA1 is the
by giovannibajo1 10y ago
This is not a pre-image attack, so you can't create a file that matches an existing SHA1. It's a collision attack, so you can create two files whose SHA1 is the same.
So what I could potentially do (given a multi-million dollar budget) is create from scratch two git repositories with different content, whose HEAD is the same. This would allow me to serve different repositories to different users.
What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel.
See also: http://crypto.stackexchange.com/questions/1173/what-are-preimage-resistance-and-collision-resistance-and-how-can-the-lack-ther http://crypto.stackexchange.com/questions/1173/what-are-prei...
- geocar 10y ago> What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel. I'm not convinced that's good enough. In git, the SHA1 is always the hash of a gzip, which is subject to tricks[1] where a header might be prepared and then some padding inserted to collide a malicious tail. [1]: http://swtch.com/r.zip http://swtch.com/r.zip
- avar 10y agoNo, Git does not hash its internal gzip'd content to produce hashes. It purely hashes the uncompressed content you give it as-is. Any compression like gzip is purely done internally as an optimization and has no impact on hashes.
- jerf 10y agoNobody's saying it's "good enough". Once we see one attack we expect to start seeing more. What's being pointed out here is that this particular attack does not let you craft custom git repos whose HEAD matches one of an existing repo. Nobody is asserting that to be generically impossible, and this new attack is at least weak evidence that such an attack may eventually be practical.
- mike_hearn 10y agoI think this is perhaps not the case. HEADs move. People contribute code. Sure, if you take a snapshot of every git repo you will ever use today and never move past those commits, this attack doesn't help. Obviously nobody will do that. People, potentially malicious people, will continue to contribute commits which they could have collided with one that does something different. I'd think that using commit hashes as a security mechanism will soon be dead.
- cesarb 10y agoThat was changed early on git's history. Originally, the object was hashed after being compressed; it was changed to be hashed before being compressed. See this commit: https://github.com/git/git/commit/d98b46f8d9a3daf965a39f8c0089c1401e0081ee https://github.com/git/git/commit/d98b46f8d9a3daf965a39f8c00...
- OJFord 10y ago> What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel. Hang on, that doesn't matter though, does it? I was under the impression that git's SHAs were to be treated as repo-wise unique; not universally. There must non-adversarial 'collisions' across repositories already, surely? I thought this attack potentially allows creating two commits in the same repo with the same hash - although it may only be possible for these to be root commits.
- rlanday 10y agoI don't think there's ever been an example of two different pieces of content hashing to the same SHA-1 before. An infinite number of such examples obviously must exist but they're incredibly improbably to encounter by accident.
- OJFord 10y agoYep, sorry, it was far too early in the day for me to appreciate the magnitude of 2^{160}. If I could downvote myself...
- deleted 10y ago[deleted]
- 0x0 10y agoIf there were collisions across repos you could just merge one into the other and you have a collision within one repo. It's previously unheard of.