Earlier this month, a seemingly significant move happened in the world of post-quantum security -
it was deploying a hybrid key encapsulation mechanism to protect the sharing of encryption secrets during the establishment of secure Transport Layer Security protocol (TLS) network connections. That is, the most popular browser globally has begun the process of quantum-proofing a major part of the public internet.
On the face of it, a significant moment. Beyond the code-breaking risk quantum machines pose, the threat of Harvest Now, Decrypt Later (HNDL) attacks on today’s data necessitates that we begin migrating now. But alongside this optimism
Put simply, Google’s action isn’t something to get overly excited about, especially not if you’re tasked with securing a sensitive organization.
Chrome Uses NIST’s Kyber Encryption
In 2022, the U.S. Department of Commerce's National Institute of Standards and Technology (NIST) selected Kyber as the candidate for general encryption, with three other post-quantum algorithms selected for digital signatures. This decision for new algorithms was long-awaited, as the threat of a functioning cryptographically relevant quantum computer is absolute – it will break through the encryption we use widely to secure our internet sessions.
Google recently announced that it has added the Kyber post-quantum encryption algorithm to version 116 of its Chrome browser. This was done using a bespoke implementation by Google within TLS, which is the widely used standard across internet communications. Google’s implementation of Kyber is ‘hybrid’, which means that traditional Elliptic Curve cryptography has also been left in place, alongside Kyber, to mitigate risk and provide continued tried and tested protection from attacks with today’s classical computers. This step also insures against someone managing to break the new Kyber algorithm.
But this does not mean that Chrome 116 users are now protected from quantum computers. This is where the caveats start.
Servers, Apps Need Security Too
Google only appears to have upgraded the Chrome browser on the client side. For any link to be quantum-safe, the server(s) in question also needs to be upgraded to Kyber, but Google doesn’t appear to have done this for its apps yet.
More important, however, are the apps beyond the Google environment. Every cloud application provider will also need to undertake this work on the server side to ensure that Chrome users can establish a secure connection with them using Kyber, which isn’t going to happen any time soon. A useful example of this would be to use Chrome to access online banking. The bank would need to have implemented Kyber, while many apps on our mobile devices may not be able to make use of the Chrome quantum-safe capability at all.
Google’s move is a step in the right direction, but application providers need to upgrade and that will take a long time and a lot of effort. This is exacerbated by the fact that Kyber itself isn’t yet fully standardized by NIST and most companies won’t even begin to move until this takes place.
Adding to this complexity is the fact that the TLS protocol, within which Google has added Kyber on a bespoke basis, is managed by the Internet Engineering Task Force (IETF). IETF hasn’t yet ratified a standard way for companies to add post-quantum algorithms as part of TLS, which also needs to happen for any widespread adoption to take place.
The final caveat is the question of how communication links deeper behind the scenes, such as data-center-to-data-center links, are protected. It’s no use securing user-to-application links if the data is harvested en masse as it moves between data centers. This will require a separate, bespoke solution, such as the quantum-safe Virtual Private Network (VPN) that is
High-Security Enterprises Must Act Urgently
The common refute you might hear to all of this is that functioning quantum machines are between five to 20 years away so we still have time on our side. But this argument is immediately undone when presented with the fact that HNDL – where sensitive data with a long shelf life is being harvested by those intending to decrypt it once a sufficiently powerful quantum computer arrives – is already happening today. You only have to look at
where internet traffic is being re-routed on unusual global paths, for no apparent reason, before returning to normal, to see where this might already be occurring in plain sight.
This is a problem, particularly if you’re a critical enterprise or any organization that is holding data with a long shelf life. This HNDL threat means that the mitigating steps need to come far sooner, if not right away. And what Google’s upgrade shows is that this is going to take some time. If you want to wait until the new post-quantum algorithms are integrated into shared, public infrastructure, you’ll likely be waiting over a decade. For example, the SHA1 deprecation was recommended four or five years before it went into effect, but eventually took over 13 years from the recommendation stage until widespread change occurred.
The long and short of it is that if you’re a high-security enterprise, the news of Google’s upgrade is not of huge significance, and even reiterates the urgency of needing to act independently, rather than being pushed by others. That is, rather than waiting for public infrastructure to be upgraded, your sights should be set on, for example, creating your own bespoke end-to-end infrastructure that’s quantum-safe by design, where everything from your business processes to day-to-day communications is protected. Here, you don’t have to wait for others to upgrade, or algorithms to be approved. You can shift the needle today.
Google has kickstarted a positive journey towards quantum-proofing its infrastructure. This is certainly a milestone, but organizations that need the most urgent protection from the quantum threat need a bespoke approach is needed and Google’s update doesn’t relieve the pressure.
Read more about:
Enter Quantum Newsletter
To get the latest quantum computing news, advice and insight, sign up to our newsletter