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