From: Andreas Ericsson <ae@op5.se>
Date: Tue, 29 Apr 2008 14:41:39 GMT
Subject: Re: About git and the use of SHA-1
Message-ID: <481733A3.4010802@op5.se>
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