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