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
next prev parent 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).