git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Dmitry PotapovNext: Nicolas Pitre
Message 19 of 38 in “About git and the use of SHA-1”
  1. Henrik AustadApr 28, 2008
  2. Daniel BarkalowApr 28, 2008
  3. Henrik AustadApr 28, 2008
  4. Daniel BarkalowApr 28, 2008
  5. Andreas EricssonApr 29, 2008
  6. Russ DillApr 29, 2008
  7. Andreas EricssonApr 29, 2008
  8. Sverre RabbelierApr 29, 2008
  9. Andreas EricssonApr 29, 2008
  10. Paolo BonziniApr 29, 2008
  11. Andreas EricssonApr 29, 2008
  12. Paolo BonziniApr 29, 2008
  13. Russ DillApr 29, 2008
  14. Jurko GospodnetićApr 29, 2008
  15. Russ DillApr 29, 2008
  16. Geoffrey IrvingApr 29, 2008
  17. Daniel BarkalowApr 29, 2008
  18. Dmitry PotapovApr 29, 2008
  19. Andreas EricssonApr 29, 2008
  20. Nicolas PitreApr 29, 2008
  21. Geoffrey IrvingApr 29, 2008
  22. Nicolas PitreApr 29, 2008
  23. Geoffrey IrvingApr 29, 2008
  24. Nicolas PitreApr 29, 2008
  25. Geoffrey IrvingApr 29, 2008
  26. Daniel BarkalowApr 29, 2008
  27. Geoffrey IrvingApr 29, 2008
  28. Fredrik SkolmliApr 29, 2008
  29. Geoffrey IrvingApr 29, 2008
  30. Fredrik SkolmliApr 29, 2008
  31. Martin LanghoffApr 30, 2008
  32. Geoffrey IrvingApr 30, 2008
  33. David BrownApr 30, 2008
  34. Martin LanghoffApr 30, 2008
  35. Matthieu MoyApr 29, 2008
  36. Fredrik SkolmliApr 29, 2008
  37. Tom WidmerApr 29, 2008
  38. Tom WidmerApr 29, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.