On Tue, 29 Apr 2008, Geoffrey Irving wrote: > On Tue, Apr 29, 2008 at 8:42 AM, Nicolas Pitre <nico@xxxxxxx> wrote: > > On Tue, 29 Apr 2008, Andreas Ericsson wrote: > > > > > But they won't, because it's impossible to add two objects with the same > > > SHA1 hash key to a git repository, since it will lazily re-use the > > > existing one. In practice, this means that in the case of an "innocent" > > > hash-collision, git will actually break by refusing to store the new > > > content. > > > > I'd also like to point out that Git usually receive "untrusted" new > > objects via the Git protocol through 'git index-pack'. If you look at > > sha1_object() in index-pack.c, you'll see that active verification > > against hash collision is performed, and the fetch will abruptly be > > aborted if ever that happens. > > > > Yes, writing a test case for this was tricky. :-) > > Here's the standard scenario for a hash collision attack, with > parties, A, B, and C: > > 1. C, the malicious one, computes the standard two pdfs with matching > sha1 hashes. > 2. C sends the valid pdf to B through a git commit, and B signs it with a tag. > 3. C grabs the signature, and then forwards the "signed" commit to A, > but substitutes the invalid pdf with the same hash. > > The fact that git will check for hash collisions within one repository > is nice, but it doesn't significantly increase the security of git > against hash collision attacks. Sure. But this is all complete handwaving until a practical collision can be demonstrated. So far the demonstration hasn't happened, practical or not. Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
