Re: About git and the use of SHA-1

>
> 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.