Post-quantum VPN protection: what hybrid ML-KEM actually does for you

Most of the encryption that protects the internet today, including the key exchange inside nearly every VPN, relies on maths that a large enough quantum computer could break. That computer does not exist yet. So why would you care about post-quantum protection now?

The real risk: harvest now, decrypt later

An attacker does not need a quantum computer today to cause you trouble later. They only need to record your encrypted traffic now and store it. If, ten or fifteen years from now, quantum computers can break the classical key exchange that protected that traffic, the recording can be decrypted after the fact.

Whether that matters depends on how long your data stays sensitive:

• Short-lived traffic (a news site, a weather app) is worthless to an attacker in 2040.
• Long-lived confidential traffic is not: legal and medical correspondence, business plans, source code, research, private messages, anything that would still hurt if it came out years from now.

If you send the second kind over public Wi-Fi, a mobile network or an ISP you don't fully trust, post-quantum protection is the part of your VPN that keeps it private in the long run, not just today.

What "hybrid ML-KEM" means

ML-KEM is the post-quantum key-exchange algorithm that NIST standardised in August 2024 as FIPS 203. SecureFox uses the ML-KEM-768 parameter set.

Hybrid means we don't replace the proven classical algorithm, we combine the two. Every protected session derives its key from both:

• X25519, the well-understood classical key exchange, and
• ML-KEM-768, the post-quantum one.

To recover the session key, an attacker has to break both. That matters because post-quantum algorithms are much newer: if a weakness were ever found in ML-KEM, X25519 would still protect you, and if quantum computers break X25519, ML-KEM still stands.

The cost is small. The hybrid handshake adds roughly 1 KB to the start of the connection. After that, your data travels with the same AES-256-GCM encryption as before, so speed, latency and battery use are unaffected.

How SecureFox applies it

You don't have to configure keys, pick special servers or edit config files:

• Every VLESS + REALITY server in the SecureFox network is provisioned with its own ML-KEM-768 key pair. The app receives the matching settings automatically when you connect.
• In the app, Settings → Post-Quantum Cryptography defaults to Auto: it negotiates the hybrid key exchange whenever the server supports it.
• If you want to be strict, choose Force hybrid. The connection then fails instead of silently falling back to classical-only. You can also turn off Allow classical fallback for fail-closed post-quantum sessions.
• Optional session-key rotation (every 10 minutes is recommended) limits how much traffic any single key protects.

What it does not cover

Being honest about the limits is part of choosing well:

• WireGuard connections are classical. WireGuard is fast and secure today, but its standard handshake is not post-quantum. If long-term confidentiality matters to you, use the VLESS protocol (or Auto with a VLESS server) rather than WireGuard.
• The VPN protects the tunnel, not the destination. Once your traffic leaves the VPN server it is protected by whatever encryption the website or app uses itself (usually HTTPS).

Who should turn it on

It is already on by default, so the question is really who should force it:

1. Journalists, lawyers, healthcare and finance professionals handling confidential material.
2. Developers and companies sending source code or internal documents over untrusted networks.
3. Anyone who would rather not bet on how quickly quantum computing arrives.

For everyone else, Auto mode gives you post-quantum protection whenever it is available, with no effort and no measurable slowdown.

Next step: open SecureFox, go to Settings → Post-Quantum Cryptography, and check that the mode is set to Auto or Force hybrid.