WireGuard earned its reputation by stripping VPN cryptography down to a handful of fixed, modern primitives: Curve25519 for key exchange, ChaCha20-Poly1305 for encryption, BLAKE2s for hashing. That simplicity is exactly why a working quantum computer would be such a problem for it. Curve25519, the elliptic-curve math that lets two WireGuard peers agree on a shared secret, is the textbook target for Shor’s algorithm. Encrypted traffic captured today could sit on a hard drive for years and still get unlocked later, once the hardware catches up. That is the “harvest now, decrypt later” scenario security teams keep bringing up, and it is why a small but growing slice of the VPN world has started bolting post-quantum key exchange onto WireGuard rather than waiting for a rewrite. The question for anyone running a VPN, a self-hosted tunnel, or a product built on top of WireGuard is no longer whether this matters, but which specific implementation path gets you real protection without giving up the speed and simplicity WireGuard is known for.
This piece compares classical WireGuard, unmodified and still running on Curve25519, against the post-quantum approach pioneered by the Rosenpass project and adopted in production by at least one major VPN provider. We’ll look at the actual byte sizes involved, who has shipped what, what it costs, and how to think about migration if you run your own WireGuard infrastructure. Every figure below is tied to an official source: NIST’s FIPS 203 standard, the Rosenpass GitHub repository, or a VPN provider’s own blog and help pages. This matters more in 2026 than it did even two years ago, because the standards body work that used to be theoretical, conference-talk material has finished, and the gap between “post-quantum cryptography exists” and “post-quantum cryptography is something you can turn on today” has mostly closed for at least one mainstream VPN product.
Classical WireGuard: What’s Actually Inside the Tunnel
WireGuard, the VPN protocol that entered the Linux mainline kernel with version 5.6 on March 29, 2020, was deliberately designed with no algorithm agility. Where OpenVPN and IPsec let administrators pick from a menu of ciphers, WireGuard hard-codes one modern suite and nothing else. The handshake follows the Noise_IK pattern: both peers already know each other’s static public key, so they skip a round trip and derive a shared session key through an ephemeral Curve25519 (X25519) exchange. Data gets encrypted with ChaCha20-Poly1305, an authenticated stream cipher pairing. Hashing runs through BLAKE2s.
Every piece of that suite is fixed, audited, and fast on ordinary CPUs without any dedicated hardware acceleration. It is also, by design, entirely classical. Nothing in the official WireGuard specification negotiates or falls back to a different key-exchange algorithm, which is a feature for auditability and a liability the day asymmetric elliptic-curve cryptography stops being hard to break. That rigidity is deliberate. WireGuard’s creator built the protocol specifically as a reaction against the sprawling cipher-suite negotiation menus in OpenVPN and IPsec, where a misconfigured server could end up negotiating a genuinely weak combination of options. Removing choice removed an entire class of configuration mistakes, and it’s a major reason security researchers have been comfortable recommending WireGuard broadly since its kernel inclusion. The same rigidity is exactly what makes bolting on a new algorithm after the fact architecturally awkward, which is why every production post-quantum implementation covered in this article works around the protocol rather than inside it.
Why the Key Exchange, Specifically, Is the Weak Link
Not every part of WireGuard’s cryptography is equally exposed. ChaCha20-Poly1305 and BLAKE2s are symmetric and hash-based primitives, and Grover’s algorithm only offers a quadratic quantum speedup against them, which is why doubling key or output length is generally considered enough of a hedge. Curve25519 is different. It depends on the elliptic-curve discrete logarithm problem, and Shor’s algorithm solves that class of problem in polynomial time on a sufficiently large, fault-tolerant quantum computer. Nobody has built that machine yet, and credible timelines for when one might exist remain genuinely uncertain. The risk isn’t that someone decrypts your VPN session next week. It’s that a session captured and stored today becomes readable a decade from now, which matters enormously for anyone whose traffic needs confidentiality measured in years rather than minutes.
The NIST Backdrop: Why This Is Happening Now
None of this exists in a vacuum. NIST spent nearly a decade running an open, international competition to pick replacement algorithms for exactly this scenario, and the results finally landed as finished federal standards on August 13, 2024. That single day produced three documents that now anchor almost every post-quantum migration conversation in the industry. FIPS 203 standardized ML-KEM, the key-encapsulation algorithm this article keeps returning to, previously known by its competition codename Kyber. FIPS 204 standardized ML-DSA, a module-lattice-based digital signature scheme, formerly Dilithium. FIPS 205 standardized SLH-DSA, a stateless hash-based signature scheme, formerly SPHINCS+.
Only one of those three matters directly for WireGuard’s key-exchange problem: ML-KEM. The signature standards address a different threat, forging identities, not reading recorded traffic, so they sit outside the scope of this comparison. Classic McEliece, the algorithm Rosenpass pairs with ML-KEM, took a different path through NIST’s process. It remains a round-four alternate candidate rather than a finished FIPS standard, but its underlying code-based hard problem has survived more than four decades of academic cryptanalysis since it was first proposed in 1978, which is exactly why projects building hybrid defenses keep choosing it as a second, structurally unrelated algorithm to pair with the newer lattice-based ML-KEM.
How Other VPN Protocols Are Handling the Same Problem
WireGuard isn’t the only tunnel protocol facing this question, and it isn’t even the first to get a standardized answer. IPsec, through its IKEv2 key-negotiation protocol, has had an official post-quantum mitigation since June 2020, four years before NIST finished ML-KEM. RFC 8784, titled “Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security” and authored by Scott Fluhrer, Panos Kampanakis, David McGrew, and Valery Smyslov, defines a mechanism that mixes a separate post-quantum preshared key into IKEv2’s session-key derivation. Structurally, it’s the same basic idea WireGuard’s ecosystem later adopted through the PSK slot: don’t replace the classical exchange, reinforce it with an independent secret an attacker also has to break.
OpenVPN sits in a less mature position. It negotiates its control channel over TLS, so in theory it could inherit post-quantum support the moment the underlying TLS library and OpenVPN’s own build both wire up a hybrid key-exchange group. In practice, no officially documented, native post-quantum key-exchange feature ships in mainline OpenVPN as of this writing. The Open Quantum Safe project maintains an OpenSSL 3.x provider that exposes ML-KEM and other post-quantum algorithms to applications willing to call into it directly, but installing that provider on a server doesn’t automatically make OpenVPN itself negotiate post-quantum key exchange. That gap, a protocol with the theoretical plumbing for post-quantum TLS but no shipped, official implementation, is a useful contrast to WireGuard’s ecosystem, where Mullvad has already moved past the experimental stage into a default-on production feature.
What “Post-Quantum WireGuard” Actually Means
There is no post-quantum fork of the WireGuard kernel module, and the official WireGuard project has not published one. Instead, the approach that has actually shipped in production runs a separate post-quantum key exchange alongside classical WireGuard and feeds the result into a mechanism WireGuard already supports: the pre-shared key (PSK) slot. The PSK was originally meant as a defense-in-depth option, a secret both peers configure out of band in addition to the Curve25519 exchange. Post-quantum WireGuard repurposes that slot to carry a key derived from a lattice- or code-based algorithm, so even if Curve25519 falls to a future quantum computer, the attacker still needs to break the second, PQC-derived secret to recover the session.
The best-documented implementation of this pattern is Rosenpass, an open-source project hosted at github.com/rosenpass/rosenpass, written in Rust, and backed by Germany’s Sovereign Tech Fund through the nonprofit Centre for the Cultivation of Technology. Rosenpass runs as its own process next to WireGuard rather than replacing any part of it. Its documentation names a hybrid pair of algorithms: Classic McEliece 460896 for the long-term static key and Kyber-512, the algorithm since standardized by NIST as ML-KEM-512, for the ephemeral exchange. The output feeds straight into WireGuard’s existing PSK field. Nothing about WireGuard’s kernel code, its wire format, or its Curve25519 handshake has to change for this to work, which is precisely why it has been deployable years before any kernel-level rewrite could realistically ship. It also means upgrading is reversible in a way a protocol rewrite wouldn’t be: if the companion process misbehaves or needs to be rolled back, an administrator can stop it and fall back to plain classical WireGuard without touching a single line of the underlying tunnel configuration.
Post-Quantum WireGuard vs Classical WireGuard: Specs Compared
The table below lines up classical WireGuard against the Rosenpass-augmented, post-quantum version side by side. Every row reflects published, verifiable specifications rather than estimates.
| Specification | Classical WireGuard | Post-Quantum WireGuard (Rosenpass-augmented) |
|---|---|---|
| Core key-exchange algorithm | Curve25519 (X25519) | Curve25519 (X25519) + Classic McEliece 460896 + ML-KEM-512 |
| Handshake pattern | Noise_IK | Noise_IK, with PQC secret injected via PSK |
| Symmetric cipher | ChaCha20-Poly1305 | ChaCha20-Poly1305 (unchanged) |
| Hash function | BLAKE2s | BLAKE2s (unchanged) |
| Public key size (key exchange) | 32 bytes (X25519) | 32 bytes (X25519) plus 1,184 bytes for an ML-KEM-768-class key, or larger for Classic McEliece |
| Requires kernel modification | No | No, runs as a companion process |
| Standardization status of PQC layer | Not applicable | Built on NIST FIPS 203 (ML-KEM); Classic McEliece is a NIST round-4 alternate candidate |
| Quantum resistance of key exchange | None | Yes, assuming at least one of the two paired algorithms holds |
| Implementation language (companion tool) | C (WireGuard kernel module) | Rust (Rosenpass) |
| Linux kernel inclusion | Mainline since kernel 5.6 (March 2020) | Runs alongside kernel WireGuard; not itself in-kernel |
| Configuration complexity | Single config file | WireGuard config plus a separate key-exchange daemon |
| Production deployment confirmed | Yes, broadly, since 2020 | Yes, at Mullvad VPN since 2022, now default on desktop |
Byte-for-Byte: How Much Bigger Are Post-Quantum Keys?
This is where the tradeoff becomes concrete. NIST’s FIPS 203, finalized on August 13, 2024, standardizes ML-KEM in three parameter sets, each trading size for security margin. A classical X25519 public key is a fixed 32 bytes, full stop. Lattice-based post-quantum keys are an order of magnitude larger, and code-based schemes like Classic McEliece are larger still on the public-key side, though its ciphertexts stay small.
| Algorithm | Public key size | Ciphertext size | Size vs X25519 (32 bytes) |
|---|---|---|---|
| X25519 (classical) | 32 bytes | 32 bytes (shared secret) | 1x, baseline |
| ML-KEM-512 (FIPS 203) | 800 bytes | 768 bytes | ~25x public key |
| ML-KEM-768 (FIPS 203) | 1,184 bytes | 1,088 bytes | 37x public key, 34x ciphertext |
| ML-KEM-1024 (FIPS 203) | 1,568 bytes | 1,568 bytes | 49x public key |
Those multipliers explain why nobody has simply swapped Curve25519 for ML-KEM inside WireGuard’s wire format. A 37x increase in handshake key material is trivial for a one-time TLS connection but a meaningfully different design constraint for a protocol built around minimal, fixed-size UDP packets. Running the post-quantum exchange as a separate out-of-band process, the way Rosenpass does, sidesteps the problem entirely: the large PQC keys get exchanged once, outside the WireGuard data path, and only a small derived PSK ever touches the WireGuard handshake itself. That architectural choice, more than any CPU benchmark, is the real engineering story behind post-quantum WireGuard.
Performance: What the Overhead Actually Costs
Independent, apples-to-apples latency benchmarks comparing a pure classical WireGuard handshake against a Rosenpass-augmented one are not publicly available as of this writing, and this article won’t invent numbers that don’t exist. What can be said with confidence, backed by official sources, breaks down into three points.
- Lattice-based key encapsulation, the operation underlying ML-KEM, is computationally cheap. The arithmetic is simple modular polynomial math, and NIST’s FIPS 203 standard was selected in part because ML-KEM runs fast even on constrained hardware. The overhead here is dominated by message size, not CPU cycles.
- The PQC exchange happens out-of-band from the WireGuard data-plane handshake. Rosenpass negotiates its hybrid secret separately and periodically, then hands WireGuard a normal-sized PSK, so the large key material never has to fit inside WireGuard’s existing packet format or its per-connection handshake budget.
- The clearest real-world performance signal is operational, not a lab benchmark: Mullvad now enables quantum-resistant tunnels by default on desktop platforms across its entire WireGuard server fleet. A VPN provider does not flip a feature to “on by default” for its whole user base if it visibly degrades connection speed.
If you need a specific millisecond figure for a capacity-planning document, the honest answer is to benchmark it yourself against your own hardware and peer count, since no verified third-party figure currently exists. Treat anyone citing an exact overhead percentage for hybrid WireGuard handshakes with skepticism unless they also name their test hardware and software versions.
Real-World Deployments: Who Actually Ships This
Mullvad VPN: From Experiment to Default
Mullvad is the furthest along of any commercial provider. It announced experimental post-quantum-safe VPN tunnels on July 11, 2022, using Classic McEliece alone, in a beta build of its app. The feature later stabilized combining Classic McEliece and Kyber, and Mullvad has since migrated to the NIST-standardized ML-KEM, replacing the earlier Kyber implementation. Quantum-resistant tunnels are now enabled by default on desktop platforms, with a toggle under Settings, VPN settings, WireGuard settings, set to Automatic or On. Mullvad bills a flat €5 per month with no tiered long-term discount structure, per its official terms of service. The rollout didn’t stop at desktop: Mullvad also published a separate announcement confirming quantum-resistant tunnels reaching its iOS app, which matters because mobile WireGuard clients are where most consumer VPN traffic actually originates, not desktop. A feature that only protects desktop sessions covers a fraction of real usage, so extending it to iOS is the step that turns this from a nice demo into something that actually closes the harvest-now-decrypt-later gap for Mullvad’s user base as a whole.
NordVPN: Post-Quantum Through NordLynx
NordVPN runs NordLynx, its own implementation layered on top of WireGuard. The company publishes an official support article explaining that post-quantum encryption is available through NordLynx specifically, not through its OpenVPN option. NordVPN’s promotional pricing runs around $3.49 per month on a long-term plan billed upfront for 27 months, against a standard month-to-month Basic price of $14.99. The important architectural detail buried in that support article is the scoping: post-quantum protection in NordVPN’s app is tied to the NordLynx protocol specifically, so a user who switches their connection to OpenVPN inside the same app loses the quantum-resistant layer entirely, even though the subscription and the app haven’t changed. That’s a pattern worth remembering across this whole comparison. Post-quantum protection in 2026 is almost always a property of a specific protocol implementation, not a blanket account-level guarantee, so the protocol toggle in your VPN app’s settings matters as much as which provider you picked.
Proton VPN: On the Roadmap, Not Yet Shipped
Proton VPN uses WireGuard as its default protocol but, per its own winter 2025-2026 product roadmap post, describes post-quantum encryption as groundwork still being laid rather than a feature already available to users. It’s a useful reminder that “WireGuard-based” and “post-quantum-ready” are not the same claim, and providers are at genuinely different stages. Proton’s broader business, built on top of Proton Mail’s end-to-end encryption reputation, puts real reputational weight behind eventually shipping this, but a roadmap entry is a stated intention, not a changelog entry, and the two shouldn’t be conflated when you’re deciding what to rely on today.
Rosenpass in the Open-Source and Public-Sector World
Rosenpass itself is free and self-hostable by anyone running their own WireGuard infrastructure. Germany’s BWI GmbH, the federal government’s IT services provider, has been associated with evaluating Rosenpass for public-sector network use, though no named, confirmed production rollout at a specific ministry or carrier has been publicly documented as of this writing. The project’s funding through the Sovereign Tech Fund signals a government-level bet that this architecture, PQC-as-companion-process rather than PQC-as-protocol-rewrite, is the practical near-term path.
ExpressVPN and Surfshark: Status Unconfirmed
Both providers market WireGuard-based protocols, but neither had an official, independently verifiable statement confirming post-quantum key exchange support at the time of this research. Readers evaluating either service for quantum resistance specifically should check the provider’s current official documentation directly rather than relying on third-party claims, including this one, since the landscape moves quickly.
Pricing: What Post-Quantum Protection Costs You
Here’s the part that surprises people: post-quantum key exchange doesn’t carry a price premium with any provider that offers it today. It ships as a feature flag inside the same subscription, or it’s free and open source if you self-host.
| Option | Price | Post-quantum status | Billing notes |
|---|---|---|---|
| Mullvad VPN | €5/month flat | Default on desktop, toggle available | No long-term discount tiers; same price month to month |
| NordVPN (Basic) | $14.99/month standard; ~$3.49/month on 27-month promo | Available via NordLynx protocol | Promotional pricing requires upfront multi-month billing |
| Proton VPN | Tiered pricing, check official site | Roadmap item, not yet shipped per official blog | WireGuard is default protocol regardless of PQC status |
| Self-hosted WireGuard + Rosenpass | $0 software cost (server hosting not included) | Full hybrid PQC via Classic McEliece + ML-KEM-512 | Requires running and maintaining a separate companion process |
| ExpressVPN / Surfshark | Provider-published pricing applies | Not independently confirmed as of publication | Verify current protocol documentation before assuming PQC support |
Security Margins: Understanding Harvest-Now-Decrypt-Later
The threat model driving all of this isn’t “a quantum computer will intercept your VPN session tomorrow.” It’s that an adversary with the resources to do bulk traffic interception, think nation-state signals intelligence, can record encrypted WireGuard sessions now and simply wait. Once a cryptographically relevant quantum computer exists, assuming one ever does, Shor’s algorithm would let that adversary recover the Curve25519 shared secret retroactively and decrypt years of stored traffic in one pass. Nothing about this requires breaking anything today. It only requires patience and storage, both of which are cheap.
That’s also why the fix doesn’t need to be perfect or permanent. A hybrid approach, pairing classical Curve25519 with a post-quantum algorithm through the PSK mechanism, only needs one of the two algorithms to hold for the session to stay secure. If ML-KEM is ever broken, Curve25519 still protects you against classical attackers. If Curve25519 falls to a future quantum computer, the PQC layer still protects you. That belt-and-suspenders logic is why hybrid designs, not pure post-quantum replacements, dominate every production deployment covered in this article.
It’s worth separating this from a concept WireGuard already has: perfect forward secrecy. Classical WireGuard already rotates its ephemeral Curve25519 keys regularly, so compromising one session’s key doesn’t expose past or future sessions to a classical attacker. Post-quantum protection solves a different problem. Forward secrecy protects you if a key leaks today. The PQC layer protects you if the entire category of elliptic-curve math stops being hard to reverse at some point in the future. You need both, and they’re not substitutes for each other.
Pros and Cons: Classical WireGuard
- Pro: Minimal attack surface, no algorithm negotiation, years of security review since its 2020 kernel inclusion.
- Pro: Smallest possible handshake size, ideal for high-connection-count servers and mobile battery life.
- Pro: Native in every modern Linux kernel with no extra daemon to run or patch.
- Con: Zero quantum resistance in its key exchange, leaving it fully exposed to harvest-now-decrypt-later.
- Con: No built-in algorithm agility if Curve25519 ever needs replacing quickly.
Pros and Cons: Post-Quantum WireGuard (Rosenpass-Augmented)
- Pro: Closes the harvest-now-decrypt-later gap without touching WireGuard’s kernel code or wire format.
- Pro: Hybrid design means only one of two independent algorithms needs to remain secure.
- Pro: Free and open source. Mullvad’s deployment proves it scales to a full commercial server fleet.
- Con: Adds an extra process to configure, run, and keep updated alongside WireGuard itself.
- Con: Classic McEliece public keys run into the hundreds of kilobytes, heavier than ML-KEM alone, though this only affects the initial exchange, not the ongoing WireGuard data path.
- Con: Ecosystem support is still thin outside Mullvad, and most commercial providers haven’t shipped it yet.
Who Should Use Which: Five Use Cases
Journalists, activists, and anyone handling long-shelf-life secrets. If the value of your traffic staying confidential extends a decade or more into the future, enable a post-quantum tunnel today. Mullvad’s default-on desktop toggle is the lowest-friction way to do this without running any infrastructure yourself.
Self-hosted WireGuard administrators. If you already run your own wg0.conf on a VPS or home server, layering a Rosenpass-style companion process on top costs nothing but setup time and gives you the same hybrid protection Mullvad ships commercially.
Everyday users with no specific long-term confidentiality need. If your VPN traffic is mostly for geo-unblocking or avoiding local network snooping on a cafe Wi-Fi, classical WireGuard remains fast, audited, and entirely adequate. There is no urgent reason to switch.
Enterprises with compliance or data-retention obligations. Organizations required to guarantee confidentiality for regulatory periods spanning many years should treat post-quantum migration as a planning item now, even if full deployment waits for broader vendor support.
Public-sector and critical-infrastructure network operators. Given the Sovereign Tech Fund’s backing of Rosenpass and reported evaluation interest from Germany’s BWI GmbH, government network teams have reason to pilot this architecture ahead of mandatory timelines rather than scrambling later.
VPN or product developers building new infrastructure. Build on a hybrid model from day one, classical Curve25519 plus a PQC-derived PSK, rather than waiting for a pure post-quantum WireGuard replacement that doesn’t exist yet and may never arrive as a single drop-in standard. Designing for the hybrid pattern from the start also avoids a painful later migration where an existing user base has to be moved onto new key material while the service stays live, which is a much harder engineering problem than including it in a product that hasn’t launched yet.
Migration Guide: Adding Post-Quantum Protection to Existing WireGuard
If you’re running classical WireGuard today and want to add hybrid post-quantum protection, the migration doesn’t touch your existing tunnel configuration. Here’s the general shape of the process.
Step 1: Confirm your WireGuard setup is current. Check your kernel version and WireGuard tools version. Nothing about this migration requires a specific minimum version beyond a working WireGuard install, since the PQC layer sits outside the protocol itself. If you’re managing more than a handful of peers, this is also the right moment to inventory which peers are physically capable of running an extra background process, since low-power embedded devices and some router firmware images may need a lighter-weight approach than a full desktop or server deployment.
# A standard classical WireGuard peer config, unchanged by this migration
[Interface]
PrivateKey = <your-existing-private-key>
Address = 10.0.0.2/24
[Peer]
PublicKey = <peer-public-key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PresharedKey = <managed-by-the-pqc-companion-process>Step 2: Install a companion post-quantum key-exchange tool on both peers. Rosenpass is the most documented open-source option, maintained at its official GitHub repository, and runs as a standalone Rust binary rather than a kernel module.
Step 3: Generate post-quantum key material separately from your WireGuard keys. The companion tool produces its own long-term and ephemeral keypairs, entirely independent of your existing Curve25519 WireGuard keys. Keep both key sets backed up separately.
Step 4: Point the PQC tool at your existing WireGuard interface and peer. The companion process negotiates its hybrid secret with the matching process on the far end, then writes the derived value into WireGuard’s pre-shared-key slot automatically, refreshing it on a schedule. This refresh cycle is worth understanding before you deploy it broadly: unlike a static PSK you type in once and forget, the companion process is continuously re-deriving fresh key material, which is what gives the setup forward secrecy on the post-quantum side as well as the classical side.
Step 5: Verify the handshake still completes and throughput looks normal. Run your usual connectivity and throughput checks. A correctly configured hybrid setup should look identical to classical WireGuard from a user’s perspective, aside from the one-time PQC key exchange at startup.
Step 6: Set the companion process to start automatically and monitor it. Treat it like any other system daemon: add it to your init system, log its output, and alert if it stops refreshing the PSK, since a stalled PQC process silently falls back to whatever static PSK was last written rather than failing the connection outright.
Step 7: Repeat for every peer pair, not just one direction. Post-quantum protection only covers links where both ends run the companion exchange. A mixed fleet, some peers upgraded and some not, still works, but only the upgraded pairs get the quantum-resistant benefit.
The Verdict: Which Should You Run in 2026?
Classical WireGuard isn’t going anywhere, and it shouldn’t. It remains the fastest, simplest, most audited option for VPN traffic without a long-term confidentiality requirement, and nothing in this comparison changes that. But for anyone whose traffic needs to stay secret past the point a quantum computer might exist, which, given the uncertainty around timelines, is a reasonable default assumption for sensitive data, the hybrid post-quantum approach is both available and free.
The data backs a clear recommendation: run hybrid post-quantum WireGuard whenever you can, because the cost is zero dollars and the only real overhead is a companion process to maintain, not a performance penalty or a subscription price increase. Mullvad has already proven this at commercial scale with a feature enabled by default across its entire fleet. NordVPN has shipped it through NordLynx. Self-hosters can add a Rosenpass-style companion process to an existing setup without touching their WireGuard configuration at all. The remaining gap isn’t technical, it’s adoption: Proton VPN, ExpressVPN, and Surfshark haven’t confirmed shipping it yet, and that’s the list to watch over the next year.
If you take one number away from this comparison, make it this one: a post-quantum key exchange adds roughly 1,184 bytes of public key and 1,088 bytes of ciphertext to a one-time handshake that used to need just 32 bytes, a 37x jump that sounds alarming until you realize it happens once per session setup, outside WireGuard’s actual data path, and costs you nothing in subscription price. Measured against what it buys, protection against an attacker who can wait a decade and still read your traffic, that’s a trade worth making for anyone who isn’t certain their data will be worthless by the time a quantum computer capable of breaking Curve25519 actually gets built.
Frequently Asked Questions
Does post-quantum WireGuard replace Curve25519 entirely?
No. Every production deployment covered here, including Mullvad’s and the Rosenpass reference design, runs Curve25519 alongside the post-quantum algorithm in a hybrid configuration. Classical WireGuard’s handshake is untouched. The PQC-derived secret is layered on top through the pre-shared-key mechanism.
Will enabling post-quantum protection slow down my VPN connection?
No verified third-party benchmark currently measures the exact overhead, but Mullvad enabling it by default across its full desktop user base is strong operational evidence that the impact is small enough not to require an opt-in warning. The overhead that does exist is concentrated almost entirely in the one-time handshake, where a few extra kilobytes of key material get exchanged before your session starts, not in the ongoing encrypted data stream, which still runs through the same ChaCha20-Poly1305 cipher at the same speed it always has.
Is Rosenpass the only way to get post-quantum WireGuard?
It’s the most documented open-source option, but it isn’t the only implementation path. Mullvad built its own quantum-resistant tunnel feature combining Classic McEliece and ML-KEM rather than adopting Rosenpass directly, achieving the same PSK-injection pattern through its own code. Any implementation that follows this general architecture, negotiate a hybrid post-quantum secret out of band, then feed it into WireGuard’s existing PSK field, counts as post-quantum WireGuard in the broad sense this article uses, regardless of whose codebase does the negotiating.
What happens if ML-KEM is broken in the future?
Because deployments are hybrid, a break in ML-KEM alone wouldn’t expose your traffic. Classical Curve25519 would still provide protection against any attacker who doesn’t additionally have a working quantum computer, and vice versa if Curve25519 falls first.
Do I need special hardware to use post-quantum WireGuard?
No. The post-quantum layer runs as ordinary software on the same CPU already running WireGuard. It requires enough spare compute to run an extra lightweight process, which any device capable of running WireGuard itself can typically handle.
Why don’t all VPN providers support this yet?
Partly timeline, partly priority. NIST only finalized ML-KEM in FIPS 203 in August 2024, and integrating any new cryptographic layer into a production VPN client takes engineering time and testing, including interoperability testing across every platform the client supports, from desktop operating systems down to mobile and router firmware. Proton VPN’s own roadmap explicitly frames this as groundwork still being laid rather than a feature ready to ship, and a provider the size of ExpressVPN or Surfshark has to coordinate the same kind of rollout across a much larger existing user base, where a mistake in a cryptographic rollout is far more costly to walk back than it would be for a smaller team.
Is Classic McEliece better than ML-KEM for this use case?
They solve different problems in the same hybrid stack rather than competing directly. Classic McEliece has an unusually large public key but a small ciphertext and a long academic security track record. ML-KEM has a far smaller public key and is the NIST-standardized default. Running both together, as Rosenpass and Mullvad do, means an attacker has to break two structurally different hard problems instead of one.
Should I wait for an official WireGuard kernel update instead of using a companion tool?
There’s no public timeline for a kernel-level post-quantum WireGuard update, and the companion-process approach is already running in production today at zero cost. Waiting means staying exposed to harvest-now-decrypt-later for however long that wait turns out to be, and because nobody can say with confidence when a cryptographically relevant quantum computer will exist, that unknown waiting period is itself the risk. A companion process you can deploy this week closes that gap immediately rather than leaving it open on the hope that a cleaner, kernel-native solution arrives before it matters.
