LINUX FOUNDER Linus Torvalds was warned in 2005 that the use of the SHA-1 hash to sign code in Linux and Git was insecure and urged to shift to something better protected, but rejected the advice outright.
Free software evangelist John Gilmore warned Torvalds ten years ago that "SHA1 has been broken; it's possible to generate two different blobs that hash to the same SHA1 hash".
Gilmore penned his warning to Torvalds in April 2005, when MD5 had already been cracked and SHA1 remained "hard to crack" - but still crackable.
"Since we don't have a reliable long-term hash function today, you'll have to change hash functions a few years out. Some foresight now will save much later pain in keeping big trees like the kernel secure. Either that, or you'll want to re-examine Git's security assumptions now: what are the implications if multiple different blobs can be intentionally generated that have the same hash?
"My initial guess is that changing has functions will be easier than making Git work in the presence of unreliable hashing," wrote Gilmore, who advised Torvalds to "make sure the code and the repositories are modular [so] they don't care what hash function is in use".
"Whether that means making a single Git repository able to use several hash functions, or merely making it possible to have one repository that uses SHA1 and another that uses some future 'wonder hash', is a system design decision for you and the Git contributors to make."
Gilmore further advised adding support for SHA256 as well as SHA1 and to remove "wired in dependencies on the names or lengths of hashes".
Torvalds, however, was unmoved. First, he disputed whether the SHA1 hash had really been broken, but added that the SHA1 hash implemented in Git wasn't necessarily intended to be cryptographically secure.
"Security doesn't actually depend on the hash being cryptographic, and all Git really wants is to avoid collisions, ie, it wants it to hash the contents well. That, SHA1 definitely does, and even a MD5 [checksum] would suffice," wrote Torvalds.
He added that, in any case, cracking SHA1 would be "expensive" and that it represented just one layer of Git's security model.
"To really break a Git archive," Torvalds continued, "you need to:
* Be able to replace an existing SHA1 hash'ed object with one that hashes to the same thing (_not_ the breakage that has been shown to be possible already);
* The replacement has to still honour all the other Git consistency checks (even "blob" objects have them: they need to have a valid header with a valid length, so it's not sufficient to just find another object that hashes to the right thing, you have to find an object with a valid header that hashes to the right thing);
* You have to break in to _all_ archives that already have that object and replace it quietly enough that nobody notices."
"Quite frankly, it's not worth worrying about. It's a hell of a lot easier to just break a source archive with other means (ie, pay a developer ten million dollars to just insert the back door you want inserted)," he concluded.
The exchange came to light after security researchers at Google and Amsterdam-based Centrum Wiskunde & Informatica (CWI) demonstrated a 'hash collision' that could be used by a determined hacker to undermine the integrity of code uploaded to Github, as well as the Linux kernel.
Torvalds point of view hasn't changed, and in an email sent over the weekend he reiterated his lack of concern.
"Put another way: I doubt the sky is falling for Git as a source control management tool. Do we want to migrate to another hash? Yes. Is it game over for SHA-1 like people want to say? Probably not," wrote Torvalds.
"I haven't seen the attack details, but I bet: (a) the fact that we have a separate size encoding makes it much harder to do on Git objects in the first place (b) we can probably easily add some extra sanity checks to the opaque data we do have, to make it much harder to do the hiding of random data that these attacks pretty much always depend on." µ
But don't expect laptop prices
Vulnerability targets hardware created by Infineon Technologies
Expect something commercial in 2019
Ex-employees say bugs were stolen and used in future attacks