Git and the security of SHA-1

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?.

16 thoughts on “Git and the security of SHA-1”

Joe Buck January 27, 2009 at 2:48 am

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.

Reply ↓

KT January 27, 2009 at 7:06 am

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).

http://kerneltrap.org/mailarchive/git/2006/8/28/211065

Reply ↓

Karl January 29, 2009 at 6:43 pm

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

Reply ↓

Andre October 27, 2009 at 8:24 pm

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.

Reply ↓

Jojo January 2, 2010 at 7:48 pm

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

Reply ↓

test king February 2, 2010 at 7:18 am

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.

Reply ↓

Gutschein February 11, 2010 at 8:26 am

“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…)

Reply ↓