git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Geoffrey Irving" <irving@naml.us>
To: "Nicolas Pitre" <nico@cam.org>
Cc: "Andreas Ericsson" <ae@op5.se>,
	"Dmitry Potapov" <dpotapov@gmail.com>,
	"Henrik Austad" <henrikau@orakel.ntnu.no>,
	git@vger.kernel.org
Subject: Re: About git and the use of SHA-1
Date: Tue, 29 Apr 2008 10:48:17 -0700	[thread overview]
Message-ID: <7f9d599f0804291048n2c706f3amdf159ffe86bdbc8@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.1.10.0804291232130.23581@xanadu.home>

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

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

  reply	other threads:[~2008-04-29 17:49 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-28 16:29 About git and the use of SHA-1 Henrik Austad
2008-04-28 19:34 ` Daniel Barkalow
2008-04-28 21:29   ` Henrik Austad
2008-04-28 22:15     ` Daniel Barkalow
2008-04-29  6:38     ` Andreas Ericsson
2008-04-29  7:09       ` Russ Dill
2008-04-29  7:21         ` Andreas Ericsson
2008-04-29 11:05           ` Sverre Rabbelier
2008-04-29 12:27             ` Andreas Ericsson
2008-04-29 13:05               ` Paolo Bonzini
2008-04-29 14:37                 ` Andreas Ericsson
2008-04-29 14:52                   ` Paolo Bonzini
2008-04-29 16:24                   ` Russ Dill
2008-04-29 12:46         ` Jurko Gospodnetić
2008-04-29 16:21           ` Russ Dill
2008-04-29 15:34   ` Geoffrey Irving
2008-04-29 16:27     ` Daniel Barkalow
2008-04-29 12:41 ` Dmitry Potapov
2008-04-29 14:41   ` Andreas Ericsson
2008-04-29 15:42     ` Nicolas Pitre
2008-04-29 15:59       ` Geoffrey Irving
2008-04-29 16:39         ` Nicolas Pitre
2008-04-29 17:48           ` Geoffrey Irving [this message]
2008-04-29 17:55             ` Nicolas Pitre
2008-04-29 18:02               ` Geoffrey Irving
2008-04-29 18:41                 ` Daniel Barkalow
2008-04-29 20:31                   ` Geoffrey Irving
2008-04-29 20:50                     ` Fredrik Skolmli
2008-04-29 21:39                       ` Geoffrey Irving
2008-04-29 21:52                         ` Fredrik Skolmli
2008-04-30  2:58                     ` Martin Langhoff
2008-04-30  5:18                       ` Geoffrey Irving
2008-04-30  5:47                         ` David Brown
2008-04-30  5:56                           ` Martin Langhoff
2008-04-29 18:17         ` Matthieu Moy
2008-04-29 18:23           ` Fredrik Skolmli
2008-04-29 15:02 ` Tom Widmer
2008-04-29 17:08 ` Tom Widmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f9d599f0804291048n2c706f3amdf159ffe86bdbc8@mail.gmail.com \
    --to=irving@naml.us \
    --cc=ae@op5.se \
    --cc=dpotapov@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=henrikau@orakel.ntnu.no \
    --cc=nico@cam.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).