Technical Whitepaper

A Post-Quantum Virtual Private Network

Last updated June 2026

Secria Team

Abstract

Secria VPN is a consumer virtual private network designed to resist both classical and quantum cryptanalytic attacks at every layer of the stack, not only the data tunnel. The WireGuard tunnel is augmented with a fresh per-connection ML-KEM-768 (FIPS 203) preshared key delivered over an X25519+ML-KEM-768 hybrid TLS channel, so the session secret is post-quantum in transit and folded into every WireGuard handshake. The control-plane API uses hybrid post-quantum TLS 1.3; server software and release binaries are authenticated with post-quantum signatures (ML-DSA and SLH-DSA); DNS is resolved by a local recursive resolver with DNSSEC validation; and traffic can be routed through a three-layer multi-hop circuit. Every VPN node runs entirely in RAM, persisting no state to disk, under a strict no-logs policy. This paper describes the protocol design, cryptographic choices, threat model, and privacy architecture of Secria VPN.

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.
  • No logs, nothing to seize. Servers run entirely in RAM and retain no traffic, IP, or connection logs. What is never written cannot be handed over.
  • Minimal, audited primitives. The design uses WireGuard and NIST-standardized post-quantum schemes rather than novel constructions, with a documented rationale 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

AdversaryCapabilitiesSecria VPN's Defense
Local network / ISPObserves and may tamper with all traffic between the device and the serverWireGuard tunnel (ChaCha20-Poly1305) encrypts and authenticates all traffic; only the encrypted tunnel is visible.
Quantum adversaryAccess to a cryptographically relevant quantum computerAn ML-KEM-768 preshared key is mixed into every WireGuard handshake; the API uses hybrid PQ TLS. Breaking the session requires defeating ML-KEM-768, not just Curve25519.
Harvest-now-decrypt-laterRecords ciphertext today for future quantum decryptionThe per-connection PSK rides an ML-KEM-768 channel and is never sent in the clear, so recorded sessions remain protected against future quantum capability.
Server seizure / compromisePhysical or remote access to a VPN nodeNodes run RAM-only; no traffic logs, IPs, or keys persist. A powered-off or seized server yields no historical user data.
Legal compulsionForces the operator to disclose data or modify serversThere are no traffic logs to disclose. A cryptographically signed warrant canary and RAM-only infrastructure provide transparency and limit what compulsion can achieve.
Supply-chain attackerAttempts to ship a malicious client or updateAll release binaries and checksums are signed with SLH-DSA (FIPS 205); clients pin the API's TLS certificate.

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.

PrimitiveStandardRole in Secria VPN
WireGuard (Noise IKpsk2)Primary tunnel: handshake and packet framing
ChaCha20-Poly1305RFC 8439Authenticated encryption of tunnelled packets
Curve25519 (ECDH)RFC 7748Classical half of the tunnel key exchange
BLAKE2sRFC 7693Hashing and key derivation in the WireGuard handshake
ML-KEM-768FIPS 203Post-quantum preshared key and hybrid TLS key exchange
X25519RFC 7748Classical half of the hybrid TLS key exchange
Ed25519 (EdDSA)RFC 8032mTLS certificates between API and nodes; JWT signing
ML-DSA-65 (Dilithium)FIPS 204Post-quantum server authentication
SLH-DSA (SPHINCS+)FIPS 205Release-binary and warrant-canary signatures
AES-256-GCMNIST SP 800-38DKey wrapping and at-rest secret encryption
Argon2idRFC 9106Password hashing

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-768 Preshared Key

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

  1. 1The client opens the connection endpoint over an X25519+ML-KEM-768 hybrid TLS 1.3 channel.
  2. 2The server generates a fresh, random 32-byte preshared key, sets it on the WireGuard peer, and returns it in the response. Because the response travels over the ML-KEM-768 channel, the PSK is post-quantum-protected in transit.
  3. 3The client installs the same PSK in its WireGuard [Peer] configuration.
  4. 4WireGuard 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-768-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, the same production approach used by other leading post-quantum VPNs.

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, runs over TLS 1.3 only, with legacy cipher suites removed. Its key exchange is the X25519+ML-KEM-768 hybrid, so control traffic is also resistant to harvest-now-decrypt-later attacks rather than only the data tunnel.

Internal connections between the central API and each node agent use mutual TLS with short-lived 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, and because they are short-lived and rotatable, 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. User passwords are hashed with Argon2id using OWASP-recommended memory-hard parameters.

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. No-Logs and Data Retention

Secria VPN is a no-logs service. It does not record traffic contents, DNS queries, browsing activity, connection timestamps, durations, source IP addresses, or per-user bandwidth. The minimal account data required to operate the service is enumerated below.

DataPurposeRetention / Storage
Account emailIdentity, recovery, billing (may be a disposable alias)Until account deletion (encrypted at rest)
Plan tierFeature and device-limit enforcementSynced on login
Device recordsDevice-limit enforcementUntil device or account removed
Active connection / circuitTunnel IP allocation and teardownRAM-only, ephemeral (minutes)
Refresh tokensSession managementSingle-use, rotated each use
Admin audit logsOperator accountabilityMinimal retention, auto-deleted

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. All release artifacts, the Linux CLI, node agent, Windows installer, macOS disk image, and Android APK, are signed with SLH-DSA (FIPS 205) during the release pipeline, and the checksum manifest is signed as well. SLH-DSA relies only on the security of hash functions, the most conservative post-quantum assumption, so the update channel resists supply-chain forgery 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 requires an email address, which may be a disposable alias and is never verified for domain ownership, plus a payment identifier. 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. For maximum payment privacy, Secria VPN accepts Monero alongside Bitcoin and card payments. 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-768 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 under a strict no-logs policy, 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

Post-Quantum at Every Layer Try Secria VPN