Last updated June 2026
Secria Team
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.
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.
| Adversary | Capabilities | Secria VPN's Defense |
|---|---|---|
| Local network / ISP | Observes and may tamper with all traffic between the device and the server | WireGuard tunnel (ChaCha20-Poly1305) encrypts and authenticates all traffic; only the encrypted tunnel is visible. |
| Quantum adversary | Access to a cryptographically relevant quantum computer | An 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-later | Records ciphertext today for future quantum decryption | The 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 / compromise | Physical or remote access to a VPN node | Nodes run RAM-only; no traffic logs, IPs, or keys persist. A powered-off or seized server yields no historical user data. |
| Legal compulsion | Forces the operator to disclose data or modify servers | There 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 attacker | Attempts to ship a malicious client or update | All release binaries and checksums are signed with SLH-DSA (FIPS 205); clients pin the API's TLS certificate. |
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.
Secria VPN composes well-studied classical primitives with NIST-standardized post-quantum schemes. Each primitive is used for a specific purpose, summarized below.
| Primitive | Standard | Role in Secria VPN |
|---|---|---|
| WireGuard (Noise IKpsk2) | — | Primary tunnel: handshake and packet framing |
| ChaCha20-Poly1305 | RFC 8439 | Authenticated encryption of tunnelled packets |
| Curve25519 (ECDH) | RFC 7748 | Classical half of the tunnel key exchange |
| BLAKE2s | RFC 7693 | Hashing and key derivation in the WireGuard handshake |
| ML-KEM-768 | FIPS 203 | Post-quantum preshared key and hybrid TLS key exchange |
| X25519 | RFC 7748 | Classical half of the hybrid TLS key exchange |
| Ed25519 (EdDSA) | RFC 8032 | mTLS certificates between API and nodes; JWT signing |
| ML-DSA-65 (Dilithium) | FIPS 204 | Post-quantum server authentication |
| SLH-DSA (SPHINCS+) | FIPS 205 | Release-binary and warrant-canary signatures |
| AES-256-GCM | NIST SP 800-38D | Key wrapping and at-rest secret encryption |
| Argon2id | RFC 9106 | Password hashing |
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.
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.
When a client connects, the following exchange establishes a post-quantum-protected session:
[Peer] configuration.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.
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.
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.
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.
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.
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.
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.
| Data | Purpose | Retention / Storage |
|---|---|---|
| Account email | Identity, recovery, billing (may be a disposable alias) | Until account deletion (encrypted at rest) |
| Plan tier | Feature and device-limit enforcement | Synced on login |
| Device records | Device-limit enforcement | Until device or account removed |
| Active connection / circuit | Tunnel IP allocation and teardown | RAM-only, ephemeral (minutes) |
| Refresh tokens | Session management | Single-use, rotated each use |
| Admin audit logs | Operator accountability | Minimal 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.
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.
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.
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.
This document describes the Secria VPN protocol as implemented at the time of writing (June 2026).
For security inquiries, contact: hq@secria.me