A post-quantum virtual private network

1. Introduction#

A virtual private network encrypts the path between a user's device and the wider internet, preventing the local network, the internet service provider, and on-path observers from reading or tampering with traffic. Modern VPNs have largely standardized on WireGuard, a minimal and formally analyzed protocol that provides strong forward secrecy with classical elliptic-curve cryptography.

That classical foundation is the problem. WireGuard's Curve25519 key exchange, like the elliptic-curve and RSA cryptography securing the rest of the internet, is vulnerable to Shor's algorithm on a cryptographically relevant quantum computer (CRQC). The "harvest now, decrypt later" attack makes this urgent today: a well-resourced adversary can passively record encrypted VPN traffic now and decrypt it years later once a CRQC exists. A VPN tunnel is a high-value target for this attack because it carries the user's entire connection in a single stream.

Most "post-quantum" VPNs, where they exist at all, add a quantum-resistant key exchange to the tunnel and stop there, leaving the control API, server authentication, software-update channel, and DNS resolver on purely classical cryptography. Secria VPN takes a different position: post-quantum protection at every layer. This paper documents how each layer is constructed and why.

1.1 Design principles#

• Post-quantum at every layer. The tunnel, the API transport, server authentication, software signing, and DNS are each protected against quantum adversaries, not just the data path.
• Nothing on disk. Secria VPN keeps no activity logs. We do not record browsing, DNS queries or traffic contents. While a session is live the service holds the account and device it belongs to, the server in use and the time it started; that record is removed when the session ends. Servers run RAM-only, so there is nothing to hand over and nothing persists if a server is powered off.
• Standard primitives. The design uses WireGuard and NIST-standardized post-quantum schemes rather than new constructions, with a written reason for every choice.
• Defense against the simultaneous-initiation race. The post-quantum key delivery is client-initiated request/response, structurally avoiding the failure modes of symmetric key-exchange daemons.
• Native clients, consistent behavior. The same protocol operates across iOS, Android, Windows, macOS, and Linux, each with certificate pinning and an OS-level kill switch.

2. Threat model#

2.1 Adversary capabilities#

2.2 Scope and limitations#

Secria VPN is designed to defeat ISP and network-level surveillance, IP-based tracking by websites and services, and future quantum decryption of recorded sessions. We state its boundaries plainly. Secria VPN does not protect against a compromised endpoint (malware on the user's own device); it cannot defeat a global passive adversary able to correlate traffic at both the entry and exit of the network simultaneously; and, like any hosted service, it cannot offer absolute protection against legal compulsion to modify server code, a risk mitigated, not eliminated, by RAM-only infrastructure and the warrant canary. The account model is pseudonymous rather than fully anonymous, as described in Section 12.

3. Cryptographic primitives#

3.1 Primitive selection#

Secria VPN composes well-studied classical primitives with NIST-standardized post-quantum schemes. Each primitive is used for a specific purpose, summarized below.

3.2 Why hybrid#

Wherever a post-quantum key exchange is used, it is combined with a classical one (Curve25519 / X25519) rather than replacing it. This hybrid approach means an attacker must break both the lattice scheme and the elliptic-curve scheme to recover a session key. If ML-KEM is later weakened by classical cryptanalysis, the elliptic-curve component still holds; if a quantum computer breaks the elliptic-curve component, ML-KEM still holds. The user is never worse off than with a classical-only VPN, and is strictly better off against quantum adversaries.

4. The quantum-safe tunnel#

The data tunnel is WireGuard, chosen for its minimal attack surface (roughly four thousand lines in the kernel module), formal analysis, and strong forward secrecy. WireGuard alone performs its key exchange with Curve25519, which is not quantum-resistant. Secria VPN closes that gap using WireGuard's own native preshared-key (PSK) facility.

4.1 ML-KEM-1024 preshared key#

When a client connects, the following exchange establishes a post-quantum-protected session:

1. The client generates an ephemeral ML-KEM-1024 keypair and opens the connection endpoint over an X25519+ML-KEM-768 hybrid TLS channel, sending its encapsulation key with the request.
2. The server generates a fresh, random 32-byte preshared key, sets it on the WireGuard peer, and returns it sealed to the client's ML-KEM-1024 encapsulation key. The PSK is protected twice over: by the ML-KEM-1024 envelope and by the ML-KEM-768 hybrid TLS transport carrying it.
3. The client decapsulates the envelope with its ephemeral key and installs the same PSK in its WireGuard [Peer] configuration.
4. WireGuard mixes the PSK into the symmetric key derivation of every handshake, so a session can only be decrypted by an adversary who has both the Curve25519 secrets and the ML-KEM-1024-protected PSK.

The PSK is one-shot per connection: a new key is generated on every connect, with no long-running key-exchange daemon and no periodic rotation to drift out of sync. Because the exchange is a client-initiated request/response, the simultaneous-initiation race that affects symmetric post-quantum daemons is structurally impossible.

4.2 Stealth mode#

Where WireGuard's UDP traffic is blocked or throttled, an optional stealth mode wraps the tunnel in a TLS WebSocket (WireGuard-over-WebSocket, via wstunnel). To deep-packet-inspection (DPI) systems the connection is indistinguishable from ordinary HTTPS, allowing the VPN to operate on restrictive networks.

5. API transport and server authentication#

The control plane, the API that handles authentication, server assignment, and tunnel setup, requires TLS 1.2 or later and prefers the X25519+ML-KEM-768 hybrid key exchange, so control traffic from current clients is also resistant to harvest-now-decrypt-later attacks rather than only the data tunnel. A client that cannot negotiate the hybrid falls back to classical key exchange, and the preshared key stays sealed with ML-KEM-1024 either way.

Internal connections between the central API and each node agent use mutual TLS with Ed25519 certificates issued by a private Ed25519 certificate authority. Because these certificates authenticate a channel that is already post-quantum-protected by the hybrid key exchange, classical Ed25519 is appropriate here: forging one would require breaking Ed25519 in real time rather than offline, and confidentiality never depends on the certificate algorithm. For public-facing server authentication, Secria VPN additionally uses ML-DSA-65 (FIPS 204) post-quantum signatures.

Session tokens are signed with Ed25519. Access tokens are short-lived; refresh tokens are single-use and rotated on every use. The VPN API stores no passwords: the app derives the login hash on the device with Argon2d (64 MiB, three passes) before anything is sent.

6. Private DNS#

Most VPNs forward DNS queries to a third-party resolver, which can observe every domain a user visits even when the traffic itself is encrypted. Secria VPN instead runs a local Unbound recursive resolver on its own infrastructure with DNSSEC validation enabled. Queries are resolved directly from the authoritative hierarchy and never handed to an outside resolver, so the user's browsing destinations are not exposed to a third party, and DNSSEC ensures responses are authentic and untampered.

7. Multi-hop routing#

For users who need protection against a single compromised or coerced server, Secria VPN offers an optional three-layer multi-hop circuit. Traffic is routed through an entry, a middle, and an exit node, with each hop able to see only the previous and next hop in the circuit. No single node knows both who the user is and where their traffic is going: the entry node sees the user but not the destination, and the exit node sees the destination but not the user. Circuit state is tracked only in server memory with a short time-to-live, never written to disk.

8. RAM-only infrastructure#

Every Secria VPN node runs entirely on a RAM-backed filesystem. No keys, configuration, connection state, or logs are written to persistent disk. WireGuard private keys exist only in kernel memory; the post-quantum preshared keys live only in RAM for the life of a connection. Powering a server off, or seizing it, destroys all volatile state and yields no historical user data.

Egress is constrained at the host firewall so that node traffic cannot leak outside the intended paths, and node health reports contain only coarse, bucketed aggregate metrics, such as ranges of peer counts, rather than exact figures that could fingerprint individual users.

9. Logs and data retention#

Secria VPN keeps no activity logs. We do not record browsing, DNS queries or traffic contents. While a session is live the service holds the account and device it belongs to, the server in use and the time it started; that record is removed when the session ends. Servers run RAM-only, so there is nothing to hand over and nothing persists if a server is powered off. The account data the service needs is listed below.

IP addresses used transiently for rate limiting are keyed-hashed with a frequently rotated, in-memory secret and held only briefly; raw IPs are never stored. Deleting an account removes all connections, devices, subscriptions, invoices, and tokens, and deletes the payment-processor customer record; the separate Secria Mail account is unaffected.

10. Leak protection#

• Kill switch. An OS-level kill switch blocks all traffic if the tunnel drops, preventing any packet from escaping outside the VPN.
• Traffic padding. Optional cover traffic at randomized intervals and sizes resists timing and volume analysis by making idle and active traffic harder to distinguish.
• DNS leak prevention. All DNS is resolved through the in-tunnel recursive resolver (Section 6), so queries cannot leak to the local network's resolver.
• WebRTC guidance. WebRTC can expose a real IP at the browser level, outside any VPN's control. Secria documents per-browser mitigations; the tunnel itself routes all system traffic correctly.

11. Client and supply-chain integrity#

Native clients for iOS, macOS, Android, Windows, and Linux pin the API server's TLS certificate by SHA-256 SPKI hash, so a fraudulently issued certificate is rejected even if a certificate authority is compromised. The published checksum manifests that list every release download are signed with SLH-DSA (FIPS 205). SLH-DSA relies only on the security of hash functions, the most conservative post-quantum assumption, so a tampered download fails verification even against a quantum adversary. Users installing the Android APK directly can verify its published SHA-256 hash before installation.

Operational transparency is provided by a warrant canary signed with SLH-DSA-SHA2-256s; clients can verify the signature, and its absence is a signal in itself.

12. Account model#

Secria VPN uses a deliberately pseudonymous, not fully anonymous, account model, and documents the trade-off openly. An account needs a username and a password, plus a payment identifier. With Pro, the username is also your Secria Mail address. This is necessary for abuse prevention and device-cap enforcement, for billing, for letting users see and revoke their own devices, and for account recovery. Payment is by card through our payment processor. The VPN is bundled with the Secria account: it can be subscribed on its own, or together with Secria Mail under a single plan.

13. Conclusion#

Secria VPN extends post-quantum protection beyond the tunnel to the entire service. The WireGuard data path is reinforced with a per-connection ML-KEM-1024 preshared key; the control API uses hybrid post-quantum TLS; server software and release binaries are authenticated with ML-DSA and SLH-DSA; DNS is resolved privately with DNSSEC; and traffic can be routed through a three-layer multi-hop circuit. Underpinning all of it, every node runs in RAM and keeps only the short-lived session record described in Section 9, so there is nothing to seize and nothing to surrender.

Where most VPNs secure one layer with classical cryptography and call it private, Secria VPN is built so that the data captured today cannot be unlocked by the computers of tomorrow, at every layer, by default.

Your connection carries your whole digital life. It deserves cryptography built for the future, not the past.

14. References#

1. WireGuard. Next Generation Kernel Network Tunnel. J. A. Donenfeld, NDSS 2017.
2. FIPS 203. Module-Lattice-Based Key-Encapsulation Mechanism Standard. NIST, August 2024.
3. FIPS 204. Module-Lattice-Based Digital Signature Standard (ML-DSA). NIST, August 2024.
4. FIPS 205. Stateless Hash-Based Digital Signature Standard (SLH-DSA). NIST, August 2024.
5. RFC 7748. Elliptic Curves for Security (Curve25519 / X25519). A. Langley, M. Hamburg, S. Turner, January 2016.
6. RFC 8439. ChaCha20 and Poly1305 for IETF Protocols. Y. Nir, A. Langley, June 2018.
7. RFC 8032. Edwards-Curve Digital Signature Algorithm (EdDSA). S. Josefsson, I. Liusvaara, January 2017.
8. RFC 9106. Argon2 Memory-Hard Function for Password Hashing. A. Biryukov, D. Dinu, D. Khovratovich, September 2021.
9. NIST SP 800-38D. Galois/Counter Mode (GCM) and GMAC. M. Dworkin, November 2007.
10. RFC 4033. DNS Security Introduction and Requirements (DNSSEC). R. Arends et al., March 2005.
11. draft-ietf-tls-hybrid-design. Hybrid key exchange in TLS 1.3. D. Stebila, S. Fluhrer, S. Gueron, IETF Internet-Draft.

This document describes the Secria VPN protocol as implemented at the time of writing (June 2026).

For security inquiries, contact: hq@secria.me