Don’t panic about SHA-1—fix it

Don't panic about SHA-1—fix it

Andrew Choy

Last week, Google unveiled proof that it had successfully created a collision attack against the SHA-1 hash algorithm, a security weakness long suspected to be exploitable with modern computing power.

But what does that mean in practical terms? It depends on how you use SHA-1 and in what context. The answers to those questions provide some idea of where to start moving away from SHA-1 first.

[ Expand your security career horizons with these essential certifications for smart security pros. | Discover how to secure your systems with InfoWorld’s Security Report newsletter. ]


Distributed source control system Git has been implicated as a possible victim of SHA-1 attacks. “If an attacker managed to create a SHA-1 collision for a source file object (git blob),” wrote Red Hat engineer Colin Walters, “it would affect all revisions and checkouts—invalidating the security of all GPG signed tags whose commits point to that object.”

How likely is that? Git developer David Lang put it this way: It’s one matter to construct a collision between two documents created by the same entity, and [and another to create] a collision between an existing document that someone else created and a new document that is also valid C code without huge amounts of binary in it.”

Walters is the creator of a tool, git-evtag, that generates strong (SHA-512) checksums for Git objects, which could be used to partly remediate this issue. That said, he believes Git’s is used responsibly, for the most, part, which already mitigates the risk. “[I believe that] today, GPG-signed git tags are fairly secure, especially if one is careful to ensure transport integrity (e.g. pinned TLS certificates from the origin).”

Whatever the real degree of risk, Git’s team is already moving forward to repair what’s broken. Theodore Ts’o, a chief Linux kernel contributor, noted “there are patches being discussed on the Git mailing list to integrate in the collision detector code which Google made available….” He also noted that “work to allow Git to support an alternate crypto checksum is ongoing.”

PDF paranoia

In a set of messages exchanged on the Crypotography mailing list, several experts in encryption technology and policy weighed in on the real risks.

Chief among them was Peter Gutmann, a computer scientist at the University of Auckland, New Zealand, focused on computer security issues and cryptography. “Reports of SHA-1’s demise are considerably exaggerated,” he wrote, and noted that many of the popular real-world protocols that use SHA-1, such as SSL, SSH, and IPsec, are not affected by the collision attack.

“So what is actually affected?” he wrote. “Situations where you’re creating signatures that need to be valid for a long time, and where the enormous latency between legitimate signature creation and forgery isn’t an issue.” This is why the proof of concept for the collision attack involved forging two PDF documents that had different contents but identical SHA-1 hashes. Most cryptography certificates, another possible place where long-term signatures would be used, have already stopped using SHA-1.

“Even for long-term document signing,” Gutmann went on, “these are frequently countersigned by a TSA to deal with the fact that the original signing certificate will expire after a year, in which case they’re safe as well.” In other words, the vast majority of recently signed PDFs are not at significant risk.

As David Lang put it, “It’s not time to panic, but it is one more push to make the changes to support something else.”