Linus Torvalds On Git's Use Of SHA-1: 'The Sky Isn't Falling' (zdnet.com)
Google's researchers specifically cited Git when they announced a new SHA-1 attack vector, according to ZDNet. "The researchers highlight that Linus Torvald's code version-control system Git 'strongly relies on SHA-1' for checking the integrity of file objects and commits. It is essentially possible to create two Git repositories with the same head commit hash and different contents, say, a benign source code and a backdoored one,' they note." Saturday morning, Linus responded:
First off - the sky isn't falling. There's a big difference between using a cryptographic hash for things like security signing, and using one for generating a "content identifier" for a content-addressable system like git. Secondly, the nature of this particular SHA1 attack means that it's actually pretty easy to mitigate against, and there's already been two sets of patches posted for that mitigation. And finally, there's actually a reasonably straightforward transition to some other hash that won't break the world - or even old git repositories...
The reason for using a cryptographic hash in a project like git is because it pretty much guarantees that there is no accidental clashes, and it's also a really really good error detection thing. Think of it like "parity on steroids": it's not able to correct for errors, but it's really really good at detecting corrupt data... if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice... It's not silently switching your data under from you... And finally, the "yes, git will eventually transition away from SHA1". There's a plan, it doesn't look all that nasty, and you don't even have to convert your repository. There's a lot of details to this, and it will take time, but because of the issues above, it's not like this is a critical "it has to happen now thing".
In addition, ZDNet reports, "Torvalds said on a mailing list yesterday that he's not concerned since 'Git doesn't actually just hash the data, it does prepend a type/length field to it', making it harder to attack than a PDF... Do we want to migrate to another hash? Yes. Is it game over for SHA-1 like people want to say? Probably not."
The reason for using a cryptographic hash in a project like git is because it pretty much guarantees that there is no accidental clashes, and it's also a really really good error detection thing. Think of it like "parity on steroids": it's not able to correct for errors, but it's really really good at detecting corrupt data... if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice... It's not silently switching your data under from you... And finally, the "yes, git will eventually transition away from SHA1". There's a plan, it doesn't look all that nasty, and you don't even have to convert your repository. There's a lot of details to this, and it will take time, but because of the issues above, it's not like this is a critical "it has to happen now thing".
In addition, ZDNet reports, "Torvalds said on a mailing list yesterday that he's not concerned since 'Git doesn't actually just hash the data, it does prepend a type/length field to it', making it harder to attack than a PDF... Do we want to migrate to another hash? Yes. Is it game over for SHA-1 like people want to say? Probably not."
Pretty sure I take his opinion over yours. All he did was help create the software that the majority of the entire internet runs on.
Time for Torvalds to drop the attitude and fix this
As far as I can tell, this is a non-cryptographic use of hashing. I've used MD5 in plenty of places just to get a fast (hardware-accelerated) unique ID for a chunk of data, or as a checksum. No security purpose at all.
Socialism: a lie told by totalitarians and believed by fools.
Both happened in 2005. And SHA-2 was published 4 years earlier. So yes, the sky is not falling, and git can be made secure, but it also wasn't really wise to use SHA-1 when git was implemented, first.
BTW: At the company I work for, we already replaced SHA-2 with SHA-3 for security reasons. Better safe than sorry.
As far as I can tell, this is a non-cryptographic use of hashing.
It's Non-Cryptographic until you start using GIT for alternative use cases which it was not designed for.
Code your developers write and store in Git should be trusted data, in the sense you are not trying to attack the system.
And code you accept from third parties should be reviewed by humans first to check that it is non-malicious.
Since the SHA-1 collision attack can be detected; It seems like it would be also a simple patch to Git to check before Adding or Updating a file in its repository if the file contains a SHA1 attack, And if so, spit out an error instead of saving the commit.
So yes, the sky is not falling, and git can be made secure, but it also wasn't really wise to use SHA-1 when git was implemented, first.
Why not? As the summary quotes Torvalds, this is simply used to guard against corruption. Using something stronger would have given people the wrong idea about what protections it offered. Sort of like how people who don't understand how HTTPS really works think "as long as I see the lock icon, I am OK and my transaction is safe". Even if it hadn't given people the wrong idea, it would have added computational overhead for no reason.
If your repository needs to be cryptographically verifiable, then you use gpg to sign your commits with your 8192-bit RSA key, or your EC key (choose the bit length you like), and don't forget to use SHA-256 or SHA-512 for the signature hash. Now you have Git's nicely sophisticated yet still quite performant "parity on steroids" and you also have all the cryptographic goodness that comes with properly signing commits. You don't depend upon on Git's parity implementation for that.
BTW: At the company I work for, we already replaced SHA-2 with SHA-3 for security reasons. Better safe than sorry.
If you replaced SHA-2 with SHA-3 for signature hashes on SSL/TLS certificates and for GPG signing, then that's great. If you think that SHA-3 somehow magically makes everything more secure for verifying data have not been modified in transit (e.g., installer gets corrupted while being downloaded) because you replaced all the SHA-2 hashes with SHA-3 hashes on the installer download page which is served over insecure HTTP, then I suspect you may not fully understand what threats you are trying to protect against.
Ours goes to SHA-11.
If you read Linus' whole statement, you will also find the part where he writes "yes, in git we also end up using the SHA1 when we use "real" cryptography for signing the resulting trees, so the hash does end up being part of a certain chain of trust. So we do take advantage of some of the actual security features of a good cryptographic hash, and so breaking SHA1 does have real downsides for us."
Regarding our use of SHA-3: We use crypographic hash-sums as keys to cached data items that are not permitted for everyone to request. Thus we need to make sure that the cache keys cannot be "guessed" (like from knowing a valid cache key for a similar data item).
"...the software's fault if you use..."
Anyway, want strong security? Use signed commits.
Your comment might have been funny if at least their was some algorithm called "SHA-7", but there isn't.
At least Mozilla isn't in charge of updating this, otherwise we'd get SHA-1.0.1, 1.0.2, 1.0.3, 1.1.0 ... bumped every six weeks.
It must have been something you assimilated. . . .
His arguments as to why it isn't serious are reasonable. If you want your arguments to be considered, you need to make some.
I think we've pushed this "anyone can grow up to be president" thing too far.
"Appeal to authority" is not a logical fallacy when the authority is actually an expert in the field. You'd have to be a moron not to value the opinion of a highly accomplished programmer over an AC troll on slashdot.
Appeal to authority makes a weak argument, but does not invalidate it. You have yet to provide even a weak argument to the contrary.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
Like how Heartbleed was immediately noticed and didn't sit there for two years.
This is one of those things Open Source proponents keep saying that isn't actually true, because people aren't really auditing the code.
Yeah but Aristotle was a fucking idiot.
We stand on the shoulders of giants. Those giants are standing on Aristotle's foot.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
Such troll.
Very flamebait.
Wow.
Pretty sure I take his opinion over yours. All he did was help create the software that the majority of the entire internet runs on.
Creating an OS doesn't make one a cryptography expert.
You ignorant little shitbag, you still don't have a fucking clue; this is not a cryptography issue, that's why Git doesn't need to fix it.
Once again we have another ignorant little piss-ant who thinks their ignorance is just as good as education.
Linus Torvalds = Fucktard.
Aww, did Linus tell you do go fuck yourself because you crap code you tried to get into the kernel?
He wrote a a small portion of a now popular kernel
He also wrote Git, which is topic being discussed.
You are a fool to take his word on little more than faith on anything resembling a security issue.
1. This is not a security issue.
2. Linus explained his reasoning very clearly, so nothing is being taken on "faith".
Or SHA-not-2b
BTW: At the company I work for, we already replaced SHA-2 with SHA-3 for security reasons. Better safe than sorry.
In my country, we kicked out the Shas and migrated to Ayatollahs, who have a unique uniqueness guarantee!
When you incorrectly state that a quote with only one claim is a non sequitur, the rest of your comment is probably wrong too.
That really annoys me no end. There is some gradual improvement in a specific attack, expected by everybody that has a clue and not seen as anything dramatic by the same people. And immediately a horde of people with no understanding of crypto swoop in an declare the sky to be falling and all uses of this thing are now invalid. This is really just utterly pathetic.
Example: I have to constantly defend the use of SHA1 for password hashing. (Sure, something like pbkdf2 or Argon2 should come later if the password may be low-entropy and gets stored. That is not always the case.) The thing is that password hashing has the purpose of preventing the hash being turned into a password again. Collision attacks have no impact on that at all. For a collision attack you would need to know the password and then you could find a second one with the same hash (or rather with the two-sided, much easier, variant you can find two passwords that map to the same hash). Now, these nil-whits completely overlook that the situation when using hashes in signatures always is that you already have what gets signed, which is completely different to the password situation. Still they claim "SHA1 is broken!". No it is not. It is broken for some specific _different_ application.
Why so many non-experts think they can voice a qualified opinion about a very hard mathematical topic is beyond me.
What Linus says here is exactly right and it is a statement by an expert. All those criticizing him are basically people that can put on a band-aid telling a brain-surgeon how to do his work. They just do not get it at all.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
u dont
I stopped reading there, sorry.
Socialism: a lie told by totalitarians and believed by fools.
You live in a scary world of imaginary threats, my friend.
Socialism: a lie told by totalitarians and believed by fools.