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

Geoffrey
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html