On Tue, Apr 29, 2008 at 9:39 AM, Nicolas Pitre <nico@xxxxxxx> wrote: > > 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. Sorry for the confusion: it would handwaving if I was saying git was insecure, but I'm not. I'm saying that if or when SHA1 becomes vulnerable to collision attacks, git will be insecure. Geoffrey -- 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
