git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russ Dill" <russ.dill@gmail.com>
To: "Andreas Ericsson" <ae@op5.se>
Cc: "Paolo Bonzini" <bonzini@gnu.org>,
	sverre@rabbelier.nl, "Henrik Austad" <henrikau@orakel.ntnu.no>,
	"Daniel Barkalow" <barkalow@iabervon.org>,
	git@vger.kernel.org
Subject: Re: About git and the use of SHA-1
Date: Tue, 29 Apr 2008 09:24:54 -0700	[thread overview]
Message-ID: <f9d2a5e10804290924y127d6a9frd7e883b8ab0f781f@mail.gmail.com> (raw)
In-Reply-To: <481732C0.5020208@op5.se>

On Tue, Apr 29, 2008 at 7:37 AM, Andreas Ericsson <ae@op5.se> wrote:
>
> Paolo Bonzini wrote:
>
> >
> >
> > > I can think of one way to make git a lot more resilient to hash
> > > collisions, regardless of which hash is used, namely: Add the length
> > > of the hashed object to the hash.
> > >
> >
> > Not really, because most attacks are about collisions, not second
> preimages.  They produce two 64-byte blocks (hence, same length) with the
> same hash value.
> >
> > As such, they allow to change a blob that *the attacker* injected in the
> repository.  The way the more "spectacular" attacks are devised requires a
> "language" with conditional expressions -- for documents, for example,
> Postscript is used.  If you prepare a postscript file whose code is
> >
> >   if (AAAA == BBBB)
> >     typeset document 1
> >   else
> >     typeset document 2
> >
> > where AAAA and BBBB are collisions, and you change it to "if (BBBB ==
> BBBB) the hash will be the same, but the outcome will be document 1 instead
> of document 2.
> >
> > The fact that this requires having the two "behaviors" in the blob is not
> a big deal for source code, going in the wrong branch of an "if" can be an
> attack.  On the other hand, it makes adding the length useless for collision
> attacks.  True, it wouldn't be useless for second preimage attacks, but
> SHA-1 is still secure with respect to those.
> >
> >
>
>  So what you're saying is that if someone owns a repository and adds a
>  file to it, he can then replace his entire repository with an identical
>  one where the good file is replaced with a bad one, and this will affect
>  people who clone *after* the file gets replaced.
>

No, if someone 0wnz a repository, not owns (Or really, malicious
mirror owners could be in on it). Either that or some form of
redirection attack. When you download a tarball, you can check the
signed checksum that is downloadable along with it. When you clone a
repo, you depend on signed tags.

  parent reply	other threads:[~2008-04-29 16:25 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 [this message]
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
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=f9d2a5e10804290924y127d6a9frd7e883b8ab0f781f@mail.gmail.com \
    --to=russ.dill@gmail.com \
    --cc=ae@op5.se \
    --cc=barkalow@iabervon.org \
    --cc=bonzini@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=henrikau@orakel.ntnu.no \
    --cc=sverre@rabbelier.nl \
    /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).