Re: About git and the use of SHA-1
- From
Andreas Ericsson <ae@op5.se>
- Date
- Apr 29, 2008, 14:41 UTC
- Message-ID
- <481733A3.4010802@op5.se>
- In-Reply-To
- <20080429124152.GB6160@dpotapov.dyndns.org>
Dmitry Potapov wrote:
Show 17 quoted lines
> 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.
Show 19 quoted lines
> 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