is WireGuard quantum safe WireGuard quantum resistant WireGuard post-quantum

Is WireGuard quantum-safe? Not by default. How to check

Adrian Maverick · · 11 min read

WireGuard is the protocol behind most modern VPN apps, and it was designed in the mid-2010s, before post-quantum key exchange was practical. Its authors knew that and left a door open. Whether your tunnel is quantum-safe depends on whether anyone walked through it.

Is WireGuard quantum-safe?

No, not by default. WireGuard agrees its session keys with Curve25519, an elliptic-curve method that a large quantum computer could break. It does have an optional 256-bit preshared key that is mixed into every handshake. When that key is delivered with a post-quantum algorithm such as ML-KEM, recorded WireGuard traffic stays unreadable even to a future quantum computer.

That is not a critic's reading. WireGuard's own known limitations page says: "WireGuard is not, by default, post-quantum secure. However, the pre-shared key parameter can be used to add a layer of post-quantum secrecy."

So the honest answer has two halves. The protocol alone: no. The protocol with a properly delivered preshared key: yes, for the thing that matters today, which is keeping recorded traffic secret.

Which parts of WireGuard can a quantum computer break?

WireGuard uses a short, fixed list of cryptography, published on its protocol page. Only one item on the list is exposed.

Job What WireGuard uses Quantum exposure
Agreeing on session keys Curve25519 (elliptic-curve Diffie-Hellman) Broken by Shor's algorithm on a large quantum computer
Encrypting your traffic ChaCha20-Poly1305 with 256-bit keys Holds. Quantum search only weakens symmetric keys, and 256 bits leaves a wide margin
Hashing and key derivation BLAKE2s, HKDF Holds
Optional preshared key A 256-bit symmetric secret mixed into the handshake Holds, if the key itself stayed secret

The pattern is the same one you see across the internet. Symmetric encryption, where both sides already share a key, is in good shape. NIST's post-quantum FAQ says of the quantum search attack on AES, the best-known cipher of this kind, that it is "quite likely" to "provide little or no advantage." The same reasoning covers ChaCha20 with its 256-bit keys. The weak point is public-key math, the step where two machines that have never met agree on a key over an open network.

In WireGuard that step is Curve25519. The traffic cipher is fine, but the key feeding it comes out of a calculation a quantum computer could redo from a recording.

Why it matters before quantum computers exist

Nobody has a quantum computer that can break Curve25519 today. The risk is to traffic that is copied now and kept. The WireGuard whitepaper names this exact threat: "adversaries may be recording encrypted traffic on a long term basis, in hopes of someday being able to break Curve25519 and decrypt past traffic" (Donenfeld, NDSS 2017, section 5.2).

That strategy is called harvest now, decrypt later. A VPN tunnel is an attractive thing to harvest, because one stream carries everything: browsing, app traffic, messages, logins.

WireGuard does rotate keys. A new handshake happens every few minutes, so stealing one key later doesn't unlock older sessions. That protection assumes the attacker can't solve Curve25519. A quantum attacker with a full recording can solve each handshake in turn, so key rotation alone doesn't help here.

How does the preshared key make WireGuard quantum-resistant?

The preshared key (PSK) is a random 256-bit secret that both ends of the tunnel hold in addition to their normal keys. During the handshake, WireGuard mixes it into the same chain of calculations that produces the session keys. The wg manual page describes it as "an additional layer of symmetric-key cryptography to be mixed into the already existing public-key cryptography, for post-quantum resistance."

The effect is a hybrid. To read a recorded session, an attacker now has to break Curve25519 and also know the preshared key. A quantum computer handles the first part and gets nowhere on the second, because a random 256-bit secret has no math to attack. And if the preshared key ever leaks, you are no worse off than with plain WireGuard, because Curve25519 still has to be broken too.

When no preshared key is set, WireGuard quietly uses 32 zero bytes in its place, per the protocol page. The slot is always there. By default it is empty.

Why not put post-quantum math inside WireGuard itself?

Size is one reason. WireGuard's opening handshake message is 148 bytes and fits comfortably in a single small packet. An ML-KEM-1024 public key alone is 1,568 bytes, according to Table 3 of NIST's FIPS 203, the post-quantum key exchange standard published in August 2024.

So the WireGuard project's advice is to keep the protocol as it is and do the post-quantum work next to it: "The best bet for post-quantum security is to run a truly post-quantum handshake on top of WireGuard, and then insert that key into WireGuard's pre-shared key slot." That sentence, from the known limitations page, describes how every serious post-quantum WireGuard setup works. If you want the background on ML-KEM and the other new standards, we cover them in what is post-quantum encryption?

Not every preshared key is equal

This is the part the launch announcements skip. "We use a preshared key" tells you very little on its own. Three details decide whether it protects you.

How the key reached your device. A preshared key is only as secret as its delivery. If it was generated on a website and downloaded inside a config file over an ordinary connection, a recording of that download gives a future quantum computer the key, and the protection is gone. The key needs to be agreed with a post-quantum method, or handed over on a channel that an eavesdropper never saw.

How often it changes. WireGuard's designers imagined a key that, by the time quantum computers arrive, "has been long forgotten." A key that sits in a config file for three years is the opposite. One long-lived key also means one leak exposes every recorded session that used it. A fresh key per connection limits the damage to that connection.

Whether it is on. Protection you have to find in a settings menu protects only the people who find it. Some providers ship it as an option with exceptions. NordVPN's help page, for example, describes post-quantum encryption as a toggle in the app's settings that works with one protocol and "will be disabled when you use a dedicated IP, other protocols, Obfuscated servers, or Meshnet" (NordVPN Help Center).

How to check if your WireGuard tunnel is quantum-safe

You don't have to take a marketing page's word for any of this. Depending on your setup, one of these checks takes under a minute.

If you run WireGuard yourself (Linux, macOS, a router or a home server). With the tunnel up, run:

sudo wg show

Under each peer, look for a line that reads preshared key: (hidden). The tool prints that line only when a preshared key is set. If you see the peer's endpoint and allowed IPs but no preshared key line, your tunnel is running on Curve25519 alone.

If you use a config file from a VPN provider. Open the .conf file in a text editor. A protected tunnel has a PresharedKey = ... line inside the [Peer] section. No such line means no preshared key. If the line is there, ask the two follow-up questions above: how did this file reach you, and how long will you keep using the same key?

If you use a VPN app. Most apps run WireGuard internally, so there is nothing for wg show to inspect. Check the provider's documentation instead, and look for specific answers to these:

  1. Which post-quantum algorithm produces the key, and at which strength? "ML-KEM-1024" is an answer. "Quantum-grade encryption" is not.
  2. Is a new key made for every connection?
  3. Is it on by default, on every server and every device, or is it a setting?

A provider that has built this properly will have written it down. If the documentation can't answer question 1, treat the claim as unproven.

If you set up your own tunnel between two machines. You can add a preshared key by hand: wg genpsk creates one, and it goes in both peers' configs. It only counts as post-quantum protection if you move it between the machines on a channel nobody recorded, such as a USB stick or a connection that already uses post-quantum key exchange.

How Secria VPN handles the preshared key

When we built Secria VPN, we followed the WireGuard project's advice to the letter: run a post-quantum exchange next to WireGuard and put the result in the preshared key slot.

Each time you connect, the app creates a fresh ML-KEM-1024 key pair and sends the public half over a hybrid post-quantum TLS connection. The server creates a random 32-byte preshared key for that session and returns it sealed with your ML-KEM-1024 key, so it never travels in the clear. Both sides load it into WireGuard, which mixes it into every handshake. Breaking a session then takes breaking ML-KEM-1024 as well as Curve25519.

Measured against the three questions: the key is agreed with ML-KEM-1024, the strongest of the three ML-KEM levels in FIPS 203. A new one is made on every connect. And it is on by default for every connection, with nothing to switch on. The step-by-step version is on our post-quantum VPN page.

Does post-quantum protection slow WireGuard down?

Not in normal use. The post-quantum exchange happens when you connect, and the preshared key is mixed in during handshakes. Your actual traffic is still encrypted with ChaCha20-Poly1305, exactly as in plain WireGuard, so the data path is unchanged. The only extra work is one more exchange at connect time.

Is WireGuard still secure today?

Yes. Against every attacker that exists in 2026, WireGuard's cryptography is sound, and its small, fixed design leaves little room for the configuration mistakes that hurt older VPN protocols. The quantum gap is about the future reading the present. If nothing you send through a VPN today would matter in ten or fifteen years, plain WireGuard is fine. If some of it would, the preshared key is how you close the gap, and it costs nothing in speed.

Frequently asked questions

Is WireGuard quantum-resistant? Not on its own. Its key exchange uses Curve25519, which a large quantum computer could break. With a preshared key that was agreed using a post-quantum algorithm such as ML-KEM, a recorded session can't be decrypted by breaking Curve25519 alone.

What is the WireGuard preshared key for? It is an optional 256-bit secret shared by both ends of a tunnel and mixed into each handshake. The WireGuard manual says it exists "for post-quantum resistance." It adds a symmetric layer that quantum computers have no shortcut against.

Is WireGuard's encryption itself at risk from quantum computers? The traffic cipher, ChaCha20-Poly1305 with 256-bit keys, is not the weak point. Quantum computers threaten the key exchange, where the two sides agree on those keys. Fix the key exchange and the rest of the protocol holds.

Does a preshared key make WireGuard fully post-quantum? It makes the contents of recorded traffic safe, which is what WireGuard's documentation means by "a layer of post-quantum secrecy." That is the protection that matters today, because recorded traffic is the only thing a future quantum computer can be used against.

Do I need a quantum-safe VPN now? It depends on how long your traffic needs to stay private. Recorded traffic can be decrypted years later, so protection only helps if it is on before the traffic is sent. For anything with a long shelf life, it is worth having today.

WireGuard left a slot for the quantum era. The only question for your VPN is what goes in it. Secria VPN fills it with a fresh ML-KEM-1024 key on every connection.

Sources

Checked October 11, 2026. Secria facts are from our VPN pages.

Secria fact-checks every post against primary sources. Spotted something wrong or out of date? Email hq@secria.me and we will correct it.

Back to all posts