Post-Quantum Encryption in VPNs: Harvest-Now Risk, ML-KEM and Hybrid Handshakes

Post-quantum encryption swaps the key exchange at the start of a VPN tunnel for maths that a quantum computer cannot shortcut, while the cipher encrypting your packets stays as it was. The point is narrow: an adversary who records your traffic today and later runs Shor's algorithm on it should come away with nothing.

Why traffic recorded today is the real target

No quantum machine can break a Diffie-Hellman or RSA exchange right now. An attacker with cheap storage does not need one yet: capture encrypted sessions, store them, and once hardware that runs Shor's algorithm on X25519 or RSA arrives, recover the session key and read everything. NIST puts expert estimates for such a machine anywhere from a few years to a few decades, and notes that rolling new crypto into products has historically taken 10 to 20 years. That gap is why migration starts before the hardware exists. If your data is worthless in a month, ignore all of this; if it's a source or a legal file, it matters.

The handshake changes, the cipher stays

A VPN connection has two moving parts: a public-key exchange that agrees on a session secret, and symmetric encryption of the traffic with AES-256-GCM or ChaCha20 built on it. Quantum attacks hit the first part hard and barely touch the second: Grover's algorithm at best halves a 256-bit key's strength, which the UK NCSC considers tolerable, and SHA-256 stays too. So only the key agreement gets replaced. Signatures and certificates, which prove the server's identity, can move later: forging one needs a quantum computer at the moment of connection, and old recordings don't help with that.

ML-KEM and why VPNs run it as a hybrid

NIST standardised ML-KEM (derived from CRYSTALS-Kyber) in its FIPS 203 document, final on 13 August 2024, with parameters ML-KEM-512, ML-KEM-768 and ML-KEM-1024. It is a key-encapsulation mechanism: one side publishes an encapsulation key, the other wraps a random secret into a ciphertext, and only the private key holder can unwrap it. ML-KEM-768's public key is 1,184 bytes against 32 bytes for X25519, so the handshake grows; data packets don't. The NCSC recommends ML-KEM-768 for most uses.

Careful VPN and TLS deployments pair ML-KEM with X25519: both exchanges run, and the session key derives from both results, so breaking it means defeating both schemes. The reason is humility about new maths: SIKE, a post-quantum candidate, fell to a classical attack in 2022, and in Google's earlier hybrid TLS test the X25519 layer kept the data safe.

Adding it to WireGuard, OpenVPN and IKEv2

WireGuard's own Noise_IKpsk2 handshake runs on Curve25519 and stays tiny on purpose. Rosenpass, a free open-source Rust tool, runs its own exchange with Classic McEliece and Kyber, feeds the result into the PSK slot, and refreshes it every two minutes; the project says the combination is no weaker than WireGuard alone. One catch with vendor apps: the post-quantum step often lives inside their client, so a config file exported to a router loses it unless you set a PSK yourself.

What a post-quantum tunnel still leaves open

Sessions recorded before the feature was switched on stay as exposed as ever. Your ISP still sees that your IP talks to the VPN server, plus timing and volume. A provider that logs, malware on your device, and the site's own TLS past the exit server are all outside this layer's reach.

How to read a "quantum-safe" badge

A useful claim names the algorithm (ML-KEM-768, Kyber, Classic McEliece), states whether it's hybrid and on by default, and names the protocols it covers. A line that only praises AES-256 tells you nothing, since that cipher was never the weak point. In the VPNRadarLab main ranking of 377 services, 12 state they offer post-quantum encryption, 8 state they don't, and 357 publish nothing either way (which means "not published", not "no"); the services that state post-quantum protection, ranked are listed on a dedicated page.

FAQ

Should I turn on post-quantum encryption in my VPN app?

Yes, unless something breaks. It protects only sessions that start after you enable it.

Does post-quantum key exchange slow the connection?

Only the handshake carries extra bytes. Throughput doesn't change.

Is post-quantum encryption the same as quantum cryptography?

No. Quantum key distribution relies on physics and dedicated hardware; PQC is ordinary maths on ordinary computers.

Post-quantum VPN encryption in a few lines

The threat is a recording decrypted years from now. The fix is a hybrid X25519 plus ML-KEM handshake. Metadata, logs and malware stay outside its reach.