As a quick reminder, thanks to Peter Shor and Lov Grover, classical cryptography is at risk. This is particularly true for asymmetric cryptography. When a quantum computer will be built with enough power (measured by the number of qubits it can process), algorithms such as Diffie-Hellman are no longer trustworthy! The issue is that it’s currently the cornerstone of the IPsec protocol (and also TLS). This is what we currently use to protect our VPN.
So DH was a convenient mechanism for two parties to exchange keys to use for encryption, even if the medium they were using (think Internet) was not secure. What do we do if it’s no longer an option?
The long-term solution is to replace that algorithm by another one that even a CRQC can’t break, we are slowly getting there. This is actually how we define PQC: NIST is selecting the new algorithms and IETF is incorporating them in standards.
There was no time to wait though, depending on their lifetime, data are already at risk. Threat actors are already Harvesting your encrypted traffic Now in order to Decrypt it Later (HNDL) once a Cryptographically Relevant Quantum Computer or CRQC is available.
In the meantime, another alternative has been introduced: quantum key distribution, not relying on math but on physics to exchange the keys. It’s currently available but it’s much more complex and expensive. We’ll discuss it another day.
Finally, remember the old days when you were not relying on a certificate to protect your VPN? Instead, both sides were agreeing out of band on a “pre-shared key” (PSK) to configure the VPN. Well, this could actually be quantum resistant! Each party owns the same encrypting key and we’re just relying on AES for encryption, a symmetric algorithm.
There is a catch though… people are now talking about post-quantum pre-shared keys, or PPK in short! So what would turn a PSK into a PPK?
Understanding the Protocol #
Well, to understand, we’ll have to take a closer look at the protocol…
The first thing to mention is that the PSK is actually not the key that would be used directly to encrypt the data. We need to derive a session key.
If we look at the initial IKE protocol, it looks as follows:
In order to get our encrypting key, we are going to process a few inputs. In the first step, we’ll add the pre-shared key in the mix, then in the second step, some secret generated through DH. As we have seen, DH is vulnerable to a CRQC, but we still have achieved some kind of quantum resistance thanks to the initial PSK. Obviously that would also depend on the complexity (entropy) of that key.
The IKEv2 Problem #
Then a few years later, IKEv2 has been published to address several shortcomings of the initial protocol. In this case, the session key is produced as follows:
Still two steps, but this time, you’ll notice the PSK is no longer used to generate the session keys! It’s only used for authentication. The session keys rely entirely on DH… That would be a problem!
Enter PPK (Post-Quantum Pre-Shared Keys) #
This is the reason why we are now talking about PPK. We have introduced a change to IKEv2 with RFC 8784…that is re-introducing the PSK in the mix.
In order to limit the change to the various implementations, we are keeping exactly the same mechanism as IKEv2, except that this time, once we have generated the output, we run it through one more round to mix in the “pre-shared” key again. That’s what makes that pre-shared key post-quantum…
What This Means #
The good news: You can get quantum resistance today by adding PPK to your IKEv2 VPNs.
The catch: You need to securely distribute those pre-shared keys out of band. This doesn’t scale well for large deployments, but it’s a practical interim solution while we wait for full PQC algorithm deployment.
The future: Eventually, we’ll replace DH entirely with NIST-approved post-quantum algorithms. Until then, PPK provide a bridge to quantum safety.