Git and the security of SHA-1

Posted by berto on January 27, 2009

I’ve heard quite a few times about how Git would be broken if someone found an easy way to create SHA-1 collisions.

A few years ago, after some attacks against SHA-1 were published, Linus explained that the security model of Git doesn’t depend on the hashes being cryptographically secure (although he said that it was a bonus and also mentioned a few possible problems).

There was an interesting thread in the Git mailing list about this topic: Starting to think about sha-256?.


Use this link to trackback from your own site.


Leave a response

  1. Joe Buck Tue, 27 Jan 2009 02:48:46 CEST

    Linus’s argument basically is that patches don’t automatically go into git databases; someone has to put them there. In the context of Linux, someone has to accept a patch, and merge it. So even if someone figured out how to create a patch that duplicated the SHA1-hash of some git object, they’d have to do it in a way that the patch looks credible enough to make someone else apply it, something that won’t work if it looks like line noise.

  2. KT Tue, 27 Jan 2009 07:06:13 CEST

    There won’t be a “collision” as we normally understand this word. If someone succeeds in creating a Git object which has the same hash as some previous object Git will treat them as the same object and won’t even bother looking at the new one (except for calculating the hash).

  3. Karl Thu, 29 Jan 2009 18:43:21 CEST

    I think it is time to change to sha-256.

  4. Andre Tue, 27 Oct 2009 20:24:14 CEST

    In Fahrplan of Chaos Computer Clubs 26C3 in Berlin at the end of this year I have heard from a presentation about this topic. I think sha256 is the right choice, too.

  5. Jojo Sat, 02 Jan 2010 19:48:22 CEST

    I know enough about security to understand that it is highly negligent to use sha-1 any longer.

  6. test king Tue, 02 Feb 2010 07:18:48 CEST

    I argue that sha-256 is better suited to git’s purposes, and to modern machines, than sha-1.

    Upsides to sha-256:
    1- not just a bit increase, but a stronger algorithm. there is more mixing, doing a more-than-incrementally better job at avoiding collisions.
    2 – the bit increase itself provides more hash space, theoretically reducing collisions.
    3 – properly aligned, a set of 32-byte hashes won’t straddle CPU cachelines.

    Downsides to sha-256:
    1 – git protocol/storage format change implications.
    2 – increase in storage size (20 to 32 bytes per hash).
    3 – fewer hand-optimized algorithm variants have been implemented.
    4 – likely more CPU cycles per hash, though I haven’t measured.

  7. Gutschein Thu, 11 Feb 2010 08:26:52 CEST

    “Andre” say that´s the same think are in Berlin, too. I think this year, it´s in europe, too. ( Germany, Belgium, Nederland, Greece, Polska and many more…)

  8. cairo Sun, 07 Mar 2010 21:41:36 CEST

    sha-256 is overdue. it must come soon!!!

  9. gratis Thu, 07 Oct 2010 10:58:05 CEST

    secure hash algorithm SH-1 is the follower of the SHA-0.
    And the follower of SH-1 is already in use also….and so on…

  10. Gutscheincode Sat, 05 Mar 2011 17:27:57 CEST

    It’s time to change to sha-256

  11. Ryan Sat, 06 Oct 2012 02:28:44 CEST

    @Jojo, well even so, you clearly know NOTHING about git. Moron.

  12. Paul Sun, 28 Oct 2012 05:41:08 CEST

    Oh come on guys… in 99% of use cases it ABSOLUTELY doesn’t matter if it’s strong or not and even md5 would do. It doesn’t need to be secure.

    Sha-256 is slower, takes up more space and provides almost zero additional value. Perhaps could be an option for security maniacs.