All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Dmitry Potapov <dpotapov@gmail.com>
Cc: 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 16:41:39 +0200	[thread overview]
Message-ID: <481733A3.4010802@op5.se> (raw)
In-Reply-To: <20080429124152.GB6160@dpotapov.dyndns.org>

Dmitry Potapov wrote:
> On Mon, Apr 28, 2008 at 06:29:07PM +0200, Henrik Austad wrote:
>> As discussed in [1], SHA-1 is not as secure as it once was (and this was in 
>> 2005), and I'm wondering - are there any plans for migrating to another 
>> hash-algorithm? I.e. SHA-2, whirlpool..
> 
> SHA-1 is broken in the sense that it requires computation less than
> finding a collision  by brute force (2^80). It is still very costly and
> AFAIK no one yet has found a single collision for SHA-1 yet, but even if
> such a collision is found, the question is how it can be exploit?
> 
> This collision cannot be used to replace any existing code in Git. The
> only way to exploit this collision is to submit a patch based on one
> sequence to the maintainer and it should look legitimate to be accepted
> and then create another blob with malicious code based on the other
> sequence, so the second blob has the same SHA-1 then anyone who pulls
> from you will get malicious code.
> 

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.

> However, it is tricky to create these two blobs -- one which should pass
> inspection and look like as a real improvement but the other one that
> should do what you want. All what you have is two sequences of 20 bytes
> with the same SHA-1 and you have no control over them. For some binary
> files, it is possible by including both good and bad contents in the
> submitted blob and using one sequence in the right place to hide the bad
> part and make only the good one active/visible. Then the other blob will
> be almost the same but contains the other sequence, which is used to
> activate the bad part. This can work if the maintainer cannot see
> everything but only the "visible" part. However, I don't think you can
> do anything like that with _source_ code, which is inspect. And if
> submitted code is not reviewed, there is nothing that can protect you
> from malicious code getting into the repository (and even worse it will
> get directly into the official repository!).
> 
> So, I don't think we have to worry much about possibility a collision
> attack, but only about preimage attacks; and a preimage attack on SHA-1
> is far away from reality.
> 

Right.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

  reply	other threads:[~2008-04-29 14:43 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 [this message]
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=481733A3.4010802@op5.se \
    --to=ae@op5.se \
    --cc=dpotapov@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=henrikau@orakel.ntnu.no \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.