Comment by Perseids | Hacker News Reader

Comment by Perseids | Hacker News Reader

Parent Full thread

To be honest I don't buy his argument. If it is not about security, why not use md5? It is faster after all and gives you the same protection against accidental data corruption as sha1. And if he cared about security then he should have chosen sha256 or sha512, the latter of which is even faster than sha1 on 64bit systems [1] and can be truncated if you think it is too long.

And really there is no denying that git relies on the security of sha1, especially its second preimage resistance[2]. Otherwise all the signed Linux releases would be useless, because you could exchange the files in the release with your own, malicious ones. Even collision resistance is important, as if you are a rogue kernel developer you can craft two files with identical hashes: One that passes scrutiny upstream and one that has a subtle backdoor. If it is in one those binary blobs there is a very low chance of it ever being found.

My guess is that he did not really put more than 5 minutes of thought into the decision. He has a track record of mediocre understanding of and low regard for cryptographic topics, see for example: http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117... .

[1] http://bench.cr.yp.to/results-hash.html

[2] You cannot find another file with the same hash as the given file.

Intel is adding native SHA instructions to x86... so sha1 will probably be much faster on those CPUs.

http://en.wikipedia.org/wiki/Intel_SHA_extensions

Interesting…

Note that they also add sha256 specific instructions. Which is good, because sha1 should no longer be used for new application and existing application should definitely start looking into an update path. See [1] for a rough estimate how fast the existing (publicly known) attacks become feasible.

I hope they are also working on implementing the sha3 permutation. That would allow for some really cool features to be super fast and simple like authenticated encryption or reseedable pseudo random number generation[2].

[1] https://www.schneier.com/blog/archives/2012/10/when_will_we_... [2] For details see section 5 and 6 of https://eprint.iacr.org/2011/499.pdf

I am not sure I buy it either. To me it comes off as cognitive dissonance between the party line of "don't invent your own crypto" and the pervasive love and acceptance of Git.

No one wants to say that Git, on which many of our SCM processes are now built, is suspect. But also no one wants to argue that Linus is somehow an exception to the rule against amateur cryptography.

So what we're left with a somewhat ambiguous situation where Git is described as not being crypto despite the fact that in practice people assume it is resistant to malicious attack.

> Git is described as not being crypto

Git has plenty of crypto in it, namely GPG (for signing tags), SSH and SSL (for transport). Using off-the-shelf crypto like this doesn't strike me as "inventing your own crypto".

> people assume it is resistant to malicious attack

Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem.

I think your argument stems from the fact that SHA1 is deemed insecure and therefore anything associated with it must also be insecure. As I said in the previous thread, git doesn't use SHA1 to make any of the guarantees that cryptography is typically used to make.

It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.

> It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.

I have evidence that people in practice use it to protect against just this sort of thing: https://news.ycombinator.com/item?id=7003900

> Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem.

Write access to your filesystem is a threat git is supposed to be secure against (more precisely: the filesystem of your git server) as Haberman has pointed out. Another incident this was relevant is the kernel.org hack: http://www.linuxfoundation.org/news-media/blogs/browse/2011/...

Furthermore, the signed tags are completely worthless if you assume second preimage resistance of sha1 to be broken. Imagine I sit between kernel.org and your computer. When you download the next Linus blessed Linux release I manipulate some of the files to contain some backdoor while still having the same sha1. As you will certainly not check every file manually for bogus content you happily compile and run the manipulated kernel and I have access to your PC via my planted backdoor.

Reply on news.ycombinator.com