I have had a couple of people email me with grave concern over the settings that our network uses for our VPN, referring to the Google (and Dutch) research project that created a SHA-1 collision on two documents.
There are a lot of things to unpack here, and we need to understand the underlying mechanics of what is going on before we can make statements about the safety or unsafety of SHA-1 in different contexts.
What Google managed to do is extremely impressive, and it wasn't something I thought we would be seeing for at least another five years. A live collision is a huge step forward in the march to kill SHA-1 and it will likely accelerate adoption of SHA-2 and increase scrutiny of KECCAK and the SHA-3 subset of it, as standards organizations like to have two algorithms ready to go at any given moment, in case one of them is found to be insecure overnight and a replacement is immediately needed for the world to continue operating online.
So let's talk about what they have done. They created a document, generated a SHA-1 hash, and through a complicated and very impressive algorithm, did an enormous amount of computations using a supercomputer for approximately a year, to allow them to add garbage data to a second forged document that would produce the same SHA-1 hash.
Here are the things that are important to note about this experiment:
They controlled the input document.
The document was relatively large in size.
It took a year to generate the collision data with a supercomputer.
The document has to be "padded" with a specific string of garbage data in order to make the hashes match.
This is an impressive feat no doubt, but this only breaks SHA-1 for this particular use-case. Attacks will continue to improve as they always do, and SHA-1 is likely to continue to become weaker over time.
Now we have to evaluate how this plays into VPNs. Certificate signing is often done using hash algorithms, but most companies that are serious about security have abandoned SHA1 for SHA2 (AKA SHA256 or SHA512) for this quite a while ago. It is not a great idea to use SHA1 for certificates anymore, even though these are a finite size, and attacking them in this way is still very implausible.
The place that Viking uses SHA-1 is in the digest algorithm for HMAC. While understanding HMAC itself can be complicated, there's a few simple facts that can help clear things up.
HMAC is an authentication method that uses hashing for verification in such a way that a collision does not break HMAC.
To be clear, even the severely compromised MD5 algorithm can be used for HMAC, and no practical attacks against HMAC have been demonstrated.
Now to break this down carefully into why SHA-1 is still okay for HMAC.
1. HMAC itself is resistant to collisions if they are found.
2. The collision demonstrated by Google is incredibly computationally expensive, it could not be executed in milliseconds, even with unbelievably powerful hardware in the hands of a nation-state's intelligence agency.
3. The collision required a large amount of crafted data to be injected into the document to make the hashes match, this would make the HMAC response too large.
4. The attack is far easier when you control the input document. If the input cannot be selected the attack is harder. In the context of HMAC this further increases the difficulty.
So finally we need to talk about WHY you would continue to use SHA1 when SHA2 is already supported by OpenVPN for HMAC. The answer is the performance hit is enormous. Using SHA-256 or SHA-512 for HMAC on a low-end device like a cheap smartphone, tablet, or consumer level router with a weak CPU causes the device to be unable to perform renegotiation within 60 seconds when the ephemeral keys expire. This causes clients to be dropped every time renegotiation takes place.
So because SHA1 HMAC is still absolutely safe, and because SHA2 HMAC creates problems, many OpenVPN based providers will continue to opt for SHA1 HMAC, and are not wrong for doing so. You are not less safe in any way.
If they are using SHA1 in areas OTHER THAN HMAC, then there is cause for concern.
I hope this clears things up a little on Google's research and how it applies to us in the privacy world.