Re: About git and the use of SHA-1

[Nicolas Pitre <nico@cam.org>]

On Tue, 29 Apr 2008, Geoffrey Irving wrote:

> On Tue, Apr 29, 2008 at 8:42 AM, Nicolas Pitre <nico@cam.org> 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