The shift from "if" to "when"

For most of the public-key era, the conversation about quantum computers breaking encryption has been theoretical. Shor's algorithm has been known since 1994. The hardware to run it at scale has not. That gap is what cryptographers call the quantum gap, and it has been closing.

NIST's response, started in 2016 and finalized in August 2024, was to standardize three post-quantum algorithms. FIPS 203 defined ML-KEM (Module-Lattice Key Encapsulation Mechanism), based on the CRYSTALS-Kyber proposal. FIPS 204 covered ML-DSA for signatures. FIPS 205 covered SLH-DSA as a hash-based fallback.

For VPNs, the relevant standard is FIPS 203. Key encapsulation is what happens during the handshake when client and server agree on the symmetric key that protects the rest of the session. If that step uses classical math, a future quantum computer can recover the key from recorded traffic.

Harvest Now, Decrypt Later

The threat model has a name: HNDL. State-level adversaries with the resources to run TSPU-class deep packet inspection also have the storage to record interesting traffic indefinitely. They do not need to break it now. They need to wait.

Estimates for cryptographically relevant quantum computers (CRQC) range from optimistic 2030 to conservative 2040. The U.S. National Security Agency has explicitly told its supply chain to migrate to post-quantum by 2035. The window for HNDL is not hypothetical: it is the gap between today's traffic capture and tomorrow's CRQC.

If your communications would be sensitive ten years from now, you need post-quantum protection ten years ago. The next best time is today.

Why lattice-based

ML-KEM rests on the hardness of a lattice problem called Module Learning With Errors (MLWE). Lattice problems have a few useful properties:

  • No known quantum speedup. Shor's algorithm efficiently solves discrete logarithm and integer factorization. It does not solve MLWE. Grover's algorithm gives a quadratic speedup on brute force, which is why parameter sets are doubled (768 instead of 384, etc.).
  • Mature analysis. Lattice cryptography has been studied since the 1990s. The hardness assumptions have survived three decades of academic attack.
  • Reasonable performance. ML-KEM 768 produces roughly 1184-byte public keys and 1088-byte ciphertexts. Acceptable for handshakes; not free, but not prohibitive.

Other candidates (code-based, isogeny-based) either lost confidence during evaluation or had performance issues. SIKE, an isogeny scheme, was famously broken in 2022 with a classical attack.

Why hybrid construction matters

A pure ML-KEM handshake would mean trusting that lattice cryptography holds. While the analysis is solid, post-quantum algorithms are younger than RSA or elliptic curves. A previously unknown attack on lattice problems would be catastrophic if there were no fallback.

The pragmatic answer is hybrid construction: combine ML-KEM with a classical algorithm such that the session key depends on both. If lattice cryptography holds, the session is post-quantum secure. If lattice cryptography is broken, the classical layer still protects against today's attackers.

The encryption suite ProxysVPN uses, mlkem768x25519plus.native.0rtt, encodes exactly this:

  • mlkem768: ML-KEM at 768 parameter set, FIPS 203
  • x25519: Curve25519 ECDH, the classical baseline
  • plus: hybrid combination, both must succeed
  • native: implemented at the protocol level, not bolted on
  • 0rtt: zero round-trip resumption enabled

0-RTT and why it matters operationally

Post-quantum keys are larger than classical ones. ML-KEM 768 ciphertext is 1088 bytes versus 32 bytes for X25519. On the first connection, this is unavoidable overhead. On subsequent connections, 0-RTT resumption uses the previously established session ticket to skip the full handshake.

For a mobile VPN client that re-establishes connections frequently (network changes, sleep cycles, application restarts), 0-RTT is the difference between a perceptible 200ms reconnect and an instant one. Without it, post-quantum overhead becomes a UX problem.

What this looks like on the wire

VLESS Reality plus ML-KEM produces a handshake that looks, to passive observers and most active probes, like a standard TLS 1.3 connection to www.intel.com. The Reality part handles the masquerade. The ML-KEM part runs inside the encrypted channel.

An adversary capturing this traffic in 2026 sees:

  • TCP connection to port 443 of a normal-looking IP
  • TLS ClientHello with SNI www.intel.com
  • Apparently valid certificate exchange
  • Encrypted application data

If they store this and bring a CRQC online in 2035, they can break the X25519 layer, reveal that it was VLESS rather than HTTPS, and... still cannot recover the application data, because the session key also depended on ML-KEM 768. That is the hybrid guarantee.

Limitations and honest caveats

Post-quantum is not magic. Some honest limitations:

  • It does not protect endpoints. If your device is compromised, the strongest cryptography in the world does not help.
  • Implementation matters. ML-KEM has subtle decapsulation paths. A flawed implementation can leak the secret. The reference implementations have been audited; in-house variants might not be.
  • Authentication is separate. ML-KEM is a KEM, not a signature scheme. Authentication still relies on classical primitives unless ML-DSA (FIPS 204) is also deployed. Most VPN ecosystems have not yet migrated authentication.
  • Larger handshake. The 1KB+ overhead matters on lossy networks. 0-RTT mitigates it for resumed connections.

Why this is not yet standard

NIST published FIPS 203 in August 2024. As of April 2026, the major VPN ecosystems are at different stages:

  • WireGuard's reference implementation does not yet support post-quantum. Several forks experiment with it.
  • OpenVPN has draft RFCs but no shipped post-quantum mode.
  • The Xray ecosystem (which includes VLESS Reality) added native ML-KEM support in late 2025. ProxysVPN is the first commercial deployment we have verified that uses it in production for end users.

The lag is not technical. The algorithms work. The lag is operational: integrating post-quantum into existing client stacks, handling key sizes, ensuring backward compatibility, and convincing operations teams to deploy something whose threat is not yet imminent.

That last reason is also why most providers will continue to delay. Provider risk and user risk are not the same. A provider has no near-term incentive to upgrade. A user with traffic that matters in 2035 does.

What to do

If you operate under any of the following threat models, post-quantum encryption is not premature:

  • You are a journalist, researcher, or activist whose source material could be weaponized retroactively.
  • You operate in a jurisdiction with state-level traffic capture (Russia and China being the operational examples in 2026).
  • You handle commercial information whose value persists beyond the quantum gap (intellectual property, M&A, government supply chain).

For ordinary streaming and casual use, classical cryptography is still adequate. The HNDL threat assumes adversaries with strategic patience and storage. Most users do not face that.

For a side-by-side review of which providers have deployed post-quantum encryption in the Russian market, see the 2026 VPN comparison. For a list of related questions, see the FAQ.