Today (February 23, 2017), Google announced the first known collision in SHA-1. They’ve posted two PDF files (which I’ve re-uploaded here and here) that both hash to the same value (38762cf7f55934b34d179ae6a4c80cadccbb7f0a). What does this mean? In short – the collision attacks on SHA-1 have gone from theoretical to proven.
[History and Significance]
What we know as “SHA-1” was first introduced in 1995 in FIPS PUB 180-1. This publication was actually a correction on a previous publication (FIPS PUB 180), intending to correct a flaw in the original SHA algorithm that gave it an estimated security strength (for the purposes of my blog post, security strength = resistance against collisions) of 33.6 bits (which is much weaker than the expected 80 bits of security strength from an ideal 160-bit hash).
Note that both of these algorithms were designed by the NSA if that has any significance to you. Note additionally, that SHA-2 was also designed by the NSA, and that SHA-3 was actually the first of the NIST SHA functions that was chosen in an open competition fashion (instead of being chosen behind closed doors). Make of that what you will…
Anyways, despite the corrections made in 1995, it has been known since around 2005 that SHA-1 provides less than the ideal 80 bits of security strength. The latest known attacks put SHA-1’s estimated security strength between 61 and 63 bits. Google’s successful “SHAttered” attack, as linked above, used about 2^63.1 SHA-1 evaluations, which seems to confirm the former estimates.
There are at least three important things to note here:
- Google’s “SHAttered” attack has a recognizable signature and required that they controlled the contents of both the original & modified files. With those caveats, it does not seem like SHAttered really has any practical applications except to serve as a visual demonstration that SHA-1 is as weak as we thought it was against collision attacks.
- Due to the fact that SHA-1 is also vulnerable to length extension attacks(similar to SHA-2, but not SHA-3)- technically, Google’s demonstration can be used to produce infinitely many SHA-1 collisions (although they’d all require a common prefix – the two PDF files).
- Google’s “SHAttered” attack puts a dollar value on a SHA-1 collision (in the $100K range). What this does is give attackers a very easy trade-off. If they see something protected by SHA-1 (say an e-commerce web site’s TLS certificate), then they can do a cost-benefit analysis: Would being able to find a collision for the e-commerce website’s TLS certificate profit me at least $100K? If so, it’s worth it to spend $100k to find the collision.
To be honest, this doesn’t change much. The SHA-1 weaknesses have already been known for a while, and actions have already been taken to transition away from it.
Back in March 2006, NIST started encouraging vendors of cryptographic modules to transition from SHA-1 to SHA-2. Specifically, they said that after 2010 SHA-1 could only be used in the context of HMAC, KDFs, and RNGs. For hash-only or digital signature applications, SHA-1 would be disallowed after 2010 (by their policy).
Looking at the archived publication of SP800-131A, it looks like that 2010 deadline was actually pushed out a bit to the end of 2013.That being said, there were a few caveats to their policy – like in SP800-52r1, page 15 where they detail that DHE and ECDHE cipher suites that use SHA-1 for digital signature generation are allowed for generating digital signatures on ephemeral parameters in TLS. The reasoning behind this exception is detailed in the document itself. It basically comes down to the fact that finding a SHA-1 collision in the context of signing ephemeral parameters does not gain the attacker anything.
While NIST ‘bit the bullet‘ fairly early on with their SHA-1 transitioning, it seems that many vendors/websites took quite a bit longer to follow suit. Chrome, Firefox and IE/Edge basically forced their hand more recently in 2016/2017 by enforcing a policy that SHA-1 based certificates would be treated as insecure and/or blocked.
The point here, however, is that the transition away from SHA-1 has already largely been made due to NIST and the browser companies’ proactive policies.
[Possible Applications and Mitigations]
In most cases where it’d matter to an ‘average’ person (e.g.: TLS for banking), I’d say that the transition away from SHA-1 has already been made and is no longer a concern (as stated in the previous section).
If you use Firefox and want to ensure that SHA-1 is no longer being used, you can always go to ‘about:config‘ and set ‘security.pki.sha1_enforcement_level‘ to a value of 1.
That being said – based on my research, there are few more mainstream cases where you may want to be careful:
- The BitTorrent protocol utilizes SHA-1, so finding a SHA-1 collision in this context might allow for an attacker to insert malicious bits into a torrent-ed file without being noticed. That being said, the BitTorrent protocol has added robustness due to the fact that (1) it uses Merkle trees, so an attacker would likely need to find multiple collisions, and (2) it’s distributed, so an attacker’s malicious ‘chunks’ may not even be propagated.
- The Git protocol utilizes SHA-1. Finding a SHA-1 collision in this context doesn’t seem to allow for much exploitation either, as explained by Linus Torvalds here.
- In some cases with software distribution, SHA-1 checksums are still used. The expectation is that a user will calculate the SHA-1 checksum locally and verify the integrity of their download to ensure that it hasn’t been corrupted in transit. Of the things I’ve listed here, this seems like the most dangerous if it’s exploited. It would allow for an attacker to distribute a file, posing it as a ‘mirror’ of the original – using the SHA-1 hash as proof that it’s clean. Then anyone who uses the attackers version could be compromised. If you see someone distributing software with a SHA-1 hash, I’d highly recommend contacting them and pushing them to transition away immediately.
And I guess that’s all I’ve got to say on that topic for a while…