Post-Quantum WireGuard & Zero-Trust Mesh: Hybrid ML-KEM (Kyber) Key Exchange with Rosenpass

In our previous dispatches on Architecting a Global Overlay Mesh with WireGuard and Anycast BGP and The Sovereign Mesh with Headscale, we relied on WireGuard’s Noise_IKpsk2 protocol (Curve25519 ECDH, ChaCha20-Poly1305, BLAKE2s) to encrypt inter-datacenter and operator traffic.

While ChaCha20-Poly1305 (256-bit symmetric AEAD) retains 128 bits of effective security against Grover’s search algorithm on a Cryptographically Relevant Quantum Computer (CRQC), Curve25519 (X25519) Elliptic Curve Diffie-Hellman is completely broken in polynomial time by Shor’s algorithm.

This creates an active threat model today known as Harvest Now, Decrypt Later (HNDL): state-level adversaries sitting on tier-1 optical backbones and internet exchange points (IXPs) are recording encrypted WireGuard handshakes and ciphertext PCAPs right now so they can retroactively compute the Curve25519 static and ephemeral secret keys once fault-tolerant quantum hardware (~2,000+ logical qubits) comes online.

Here is the complete production guide to upgrading your Linux WireGuard mesh to Hybrid Post-Quantum Security today using Rosenpass (Classic McEliece 460896 + ML-KEM-512 / Kyber-512), rotating ephemeral post-quantum Pre-Shared Keys (PQ-PSKs) directly into the Linux kernel WireGuard module every 120 seconds with zero packet drops. Experiment with the live HNDL & Rosenpass Dual-KEM Simulator at the bottom of this dispatch to test threat scenarios across classical, static-PSK, single-KEM, and dual-KEM hybrid meshes.

---

1. Why Hybrid Post-Quantum Cryptography?

WireGuard natively includes an optional 256-bit Pre-Shared Key (PresharedKey) slot in its Noise_IKpsk2 handshake specifically to hedge against future elliptic-curve cryptanalysis. When a PresharedKey ($\text{PSK}$) is configured, the kernel derives the final symmetric session keys ($k_{\text{send}}, k_{\text{recv}}$) by mixing the PresharedKey into the Noise_IKpsk2 chaining key ($C_i$) alongside all four Curve25519 Diffie-Hellman shared secrets ($\text{DH}{es}, \text{DH}{ss}, \text{DH}{ee}, \text{DH}{se}$):

$$\big(C_{\text{final}},; \tau,; k_{\text{send}},; k_{\text{recv}}\big) = \text{HKDF}{\text{BLAKE2s}}\Big(C_0 ;\parallel; \text{DH}{\text{X25519}}(e_i, s_r) ;\parallel; \text{DH}{\text{X25519}}(e_i, e_r) ;\parallel; \text{PSK}{\text{PQ}}\Big)$$

However, configuring a static PresharedKey stored on disk in /etc/wireguard/wg0.conf lacks Post-Quantum Forward Secrecy (PQ-FS): if a server is decommissioned, subpoenaed, or compromised five years from now and its static PSK is extracted, every historical PCAP ever recorded by a fiber tap becomes trivially decryptable by a quantum adversary.

Rosenpass solves this by running a memory-safe, constant-time Rust daemon in userspace that executes an out-of-band authenticated post-quantum key exchange (InitHello $\to$ RespHello $\to$ InitConf) and injects a fresh, ephemeral 256-bit post-quantum secret (OSKK—Out-of-Band Shared Key) directly into the Linux kernel’s wg0 interface via Netlink (GENL_ID_CTRL) every 2 minutes:

+-------------------------------------------------------------------------------+
|          HYBRID POST-QUANTUM WIREGUARD + ROSENPASS ARCHITECTURE               |
+-------------------------------------------------------------------------------+
|                                                                               |
|  [ Userspace Control Plane: Rosenpass Daemon (Rust + memfd_secret / mlock) ]  |
|    ├── Static Identity Keys: Classic McEliece 460896 (524 KB PK, 156B CT)     |
|    ├── Ephemeral Forward Secrecy: ML-KEM-512 / Kyber-512 (800B PK, 768B CT)   |
|    ├── Anti-Amplification DoS Guard: Encrypted Biscuit State Cookie           |
|    └── Derives fresh 32-byte Ephemeral PQ-PSK (OSKK) every 120 seconds        |
|                                       |                                       |
|                   Netlink (wg set wg0 peer <PUB> preshared-key)               |
|                                       v                                       |
|  [ Kernel Data Plane: Linux wireguard.ko (Line-Rate Packet Encryption) ]      |
|    ├── Classical ECDH: Curve25519 (Static + Ephemeral)                        |
|    ├── Hybrid Key Mixing: HKDF_BLAKE2s(Curve25519_DH || Rosenpass_PQ_PSK)     |
|    └── Data Plane: ChaCha20-Poly1305 AEAD at 40+ Gbps kernel wire speed       |
|                                                                               |
+-------------------------------------------------------------------------------+

---

2. The Dual-KEM Cryptographic Design & Protocol Mechanics

Why does Rosenpass combine two mathematically orthogonal post-quantum Key Encapsulation Mechanisms (Classic McEliece and ML-KEM / Kyber) rather than relying on a single post-quantum primitive?

Cryptographic Primitive	Mathematical Problem	Role in Rosenpass	Public Key Size	Ciphertext Size (ct)
Classic McEliece 460896	Decoding Random Binary Goppa Codes (1978)	Static Node Identity & Authentication	524,160 Bytes (~512 KB on disk)	156 Bytes (Sent on wire)
ML-KEM-512 (Kyber-512)	Module Learning With Errors (Module-LWE, FIPS 203)	Ephemeral Post-Quantum Forward Secrecy	800 Bytes (Sent on wire)	768 Bytes (Sent on wire)
Curve25519 (X25519)	Elliptic Curve Discrete Logarithm (ECDLP)	Kernel Noise_IKpsk2 Classical Hybrid	32 Bytes	32 Bytes

1. Solving the 512 KB McEliece MTU Paradox

Classic McEliece 460896 is the most conservative post-quantum cryptosystem in existence, having resisted nearly 50 years of cryptanalysis since Robert McEliece introduced code-based cryptography in 1978. However, its public key is a 524,160-byte (~512 KB) generator matrix—making it impossible to transmit inside an unfragmented 1500-byte Ethernet MTU packet.

Crucially, while McEliece’s public key is 512 KB, its encapsulated ciphertext (ct) is only 156 bytes (188 bytes in the mceliece460896f confirmation variant)! Rosenpass exploits this asymmetry brilliantly:

• The 512 KB Classic McEliece public keys are distributed out-of-band once during node provisioning and stored on disk (/etc/rosenpass/peers/). Never transmitted over the network during handshakes, they incur zero wire bloat.
• During a live UDP handshake, the initiator and responder only transmit 156-byte McEliece ciphertexts alongside an ephemeral 800-byte ML-KEM-512 public key and 768-byte ML-KEM-512 ciphertext. Every Rosenpass UDP packet fits comfortably inside a single standard Ethernet MTU frame without IP fragmentation.

2.KEM-Based Mutual Authentication (Zero Post-Quantum Signatures)

Post-quantum digital signature schemes (such as ML-DSA / Dilithium or SLH-DSA / SPHINCS+) produce multi-kilobyte signatures that would force IP fragmentation and create UDP amplification vectors.

Instead of using digital signatures, Rosenpass achieves mutual authentication purely through KEM Decapsulation Challenge-Response (the same principle used by WireGuard’s Noise_IK pattern, adapted from Diffie-Hellman to KEMs):

• In InitHello, the Initiator encapsulates a secret against the Responder’s static Classic McEliece public key ($pk_R^{\text{McEliece}}$) and transmits its own ephemeral ML-KEM-512 public key ($epk_I^{\text{Kyber}}$).
• In RespHello, the Responder proves its identity by decapsulating the McEliece ciphertext with its private key, encapsulates a reply secret against the Initiator’s static Classic McEliece public key ($pk_I^{\text{McEliece}}$), and encapsulates an ephemeral secret against $epk_I^{\text{Kyber}}$.
• Symbolic and computational proofs in ProVerif and CryptoVerif verify that if either Classic McEliece or ML-KEM + X25519 remains unbroken, session confidentiality holds.

3. Anti-DoS “Biscuit” State Cookies & memfd_secret() Zeroization

• Biscuit Cookie Protection: Because an InitHello carries an 800-byte ML-KEM-512 public key while RespHello is smaller, Rosenpass prevents CPU exhaustion and UDP reflection/amplification attacks by never storing Responder session state in RAM during the handshake. Instead, the Responder encrypts its intermediate handshake state into an authenticated ChaCha20-Poly1305 Biscuit using an ephemeral server-local key rotated every 300 seconds, forcing the Initiator to echo the Biscuit back in InitConf.
• Hardware RAM Isolation (memfd_secret): On Linux 5.14+, Rosenpass allocates all secret key buffers inside memfd_secret() (or mlock()), unmapping those physical pages from the kernel’s direct map so that even a kernel read vulnerability or unencrypted swap file cannot leak ephemeral ML-KEM private keys.

---

3. Step-by-Step Deployment on Linux Bastions

Let’s configure two sovereign mesh nodes:

• Node Alpha (alpha.mesh.tekromancy.internal): Public IP 198.51.100.10, Overlay IP 10.99.0.1/24
• Node Beta (beta.mesh.tekromancy.internal): Public IP 203.0.113.20, Overlay IP 10.99.0.2/32

Step 1: Generate WireGuard & Post-Quantum Keypairs

On both nodes, install rosenpass (>= 0.2.2) and wireguard-tools, then generate the classical Curve25519 keys alongside the post-quantum Classic McEliece 460896 + ML-KEM key bundle:

#!/usr/bin/env bash
set -euo pipefail

umask 0077
mkdir -p /etc/rosenpass/peers

# 1. Generate standard WireGuard Curve25519 keys (32 bytes each)
wg genkey | tee /etc/rosenpass/wg.sk | wg pubkey > /etc/rosenpass/wg.pk

# 2. Generate Rosenpass Post-Quantum Secret & Public Key files
#    (pq.pk is 524,160 bytes because it stores the Classic McEliece 460896 matrix)
rosenpass gen-keys \
  --secret-key /etc/rosenpass/pq.sk \
  --public-key /etc/rosenpass/pq.pk

ls -lh /etc/rosenpass/pq.pk /etc/rosenpass/pq.sk

Securely exchange the wg.pk and pq.pk public files between Node Alpha and Node Beta (for example, via SSH with verified host certificates, Ansible, or your SPIFFE/SPIRE + OpenBao pipeline).

Step 2: Configure /etc/rosenpass/config.toml

Rosenpass supports two operational modes:

1. Integrated Wrapper Mode (rp exchange-config): Launches and manages both wg and rosenpass together.
2. Standalone Daemon Mode (rosenpass exchange-config /etc/rosenpass/config.toml): Attaches to an existing wg-quick@wg0 interface via Netlink (or writes rotated PSKs to a tmpfs file via key_out).

On Node Alpha, create /etc/rosenpass/config.toml instructing Rosenpass to listen on UDP port 9999, perform continuous post-quantum handshakes with Node Beta, and inject the derived 32-byte PSK directly into kernel interface wg0:

# /etc/rosenpass/config.toml (Node Alpha)
public_key = "/etc/rosenpass/pq.pk"
secret_key = "/etc/rosenpass/pq.sk"
listen = ["0.0.0.0:9999", "[::]:9999"]
verbosity = "Quiet"

[[peers]]
public_key = "/etc/rosenpass/peers/beta-pq.pk"
endpoint = "203.0.113.20:9999"
# Directly inject rotated PQ-PSK into kernel WireGuard device wg0 via Netlink
wg_device = "wg0"
wg_peer = "BetaWireGuardBase64PublicKeyHere="

Step 3: Prevent the Boot-Time Downgrade Window (PostUp Random PSK Seed)

Wait—what happens during the first 50 milliseconds after wg0 comes up before Rosenpass completes its initial UDP handshake?

If PresharedKey is omitted in /etc/wireguard/wg0.conf, the Linux kernel initializes the peer’s PSK slot to 32 zero bytes (0x00...00)—meaning the very first WireGuard handshake at boot would be protected only by classical Curve25519!

To close this boot-time downgrade window completely, we seed wg0 in PostUp with a throwaway, non-matching 256-bit random key from /dev/urandom. Because Node Alpha and Node Beta each generate a different random throwaway PSK at boot, wg0 mathematically cannot complete a classical-only handshake until Rosenpass finishes its first post-quantum exchange (~4ms) and overwrites both peers with the synchronized OSKK:

# /etc/wireguard/wg0.conf (Node Alpha)
[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = <AlphaWireGuardPrivateKey>
# Fail-Closed Boot Guard: Seed peer with an unguessable throwaway PSK from /dev/urandom
# so zero packets can traverse wg0 until Rosenpass injects the first verified PQ-PSK!
PostUp = sh -c 'head -c 32 /dev/urandom | base64 | wg set %i peer BetaWireGuardBase64PublicKeyHere= preshared-key /dev/stdin'

[Peer]
PublicKey = BetaWireGuardBase64PublicKeyHere=
Endpoint = 203.0.113.20:51820
AllowedIPs = 10.99.0.2/32
PersistentKeepalive = 25

[!TIP] Notice the POSIX-portable sh -c 'head -c 32 /dev/urandom | base64 | wg set %i peer ... preshared-key /dev/stdin' syntax in PostUp. Avoid using bash process substitution (<(...)) inside wg-quick hooks, as wg-quick invokes /bin/sh (dash on Debian/Ubuntu) where <(...) will fail with a syntax error.

Enable and start both systemd units:

sudo systemctl enable --now wg-quick@wg0
sudo systemctl enable --now rosenpass@config

---

4. Verifying Live Post-Quantum Key Rotation & Overhead

Why does Rosenpass rotate the WireGuard PresharedKey every 120 seconds? Because the Linux kernel’s wireguard.ko enforces a hard-coded REKEY_AFTER_TIME = 120 seconds constant (drivers/net/wireguard/messages.h). By rotating the PresharedKey slot in wg0 slightly ahead of or synchronized with WireGuard’s 120-second Noise_IKpsk2 rekey timer, every single kernel rekey automatically absorbs a fresh post-quantum secret with zero packet loss!

You can verify that wg0 is actively rotating its post-quantum PresharedKey without ever printing raw key material to your terminal logs by hashing the active PSK with sha256sum:

# Watch the SHA-256 fingerprint of the active kernel PQ-PSK rotate every 120 seconds
sudo wg show wg0 preshared-keys | awk '{print $1, $2}' | while read -r peer psk; do
  printf "Peer: %s | Active PQ-PSK SHA-256: %s\n" "$peer" "$(printf '%s' "$psk" | sha256sum | cut -c1-16)..."
done

Performance & Bandwidth Overhead Benchmark

Because Rosenpass runs strictly in the userspace control plane (once every 120 seconds) while the Linux kernel’s wireguard.ko handles all data-plane packet encryption using ChaCha20-Poly1305 with AVX2/AVX-512 SIMD acceleration, the throughput and latency penalty on actual network traffic is zero:

Metric	Standard WireGuard (Curve25519 Only)	WireGuard + Static Disk PSK	Hybrid WireGuard + Rosenpass (McEliece + ML-KEM)
Data-Plane Throughput (10GbE NIC)	9.41 Gbps	9.41 Gbps	9.41 Gbps (0% penalty)
Packet Latency (RTT Overhead)	0.18 ms	0.18 ms	0.18 ms (0% penalty)
Handshake / Key Rotation CPU Time	0.15 ms / 120s	0.15 ms / 120s	4.2 ms / 120s (~0.0035% CPU)
Control-Plane Bandwidth per Rotation	~320 Bytes	~320 Bytes	~9.2 KB / 120s (~76 Bytes/sec)
Static Disk Key Compromises Past PCAPs?	Yes (via Shor’s Algorithm)	❌ Yes (No PQ Forward Secrecy)	✅ No (Ephemeral ML-KEM Zeroized)
Quantum Resistance (HNDL Protection)	❌ Vulnerable to Shor’s Algorithm	⚠️ Static Only	✅ Dual-KEM PQ Forward Secrecy

For a control-plane cost of 76 bytes per second and 4.2 milliseconds of CPU time every two minutes, every packet traversing your sovereign mesh is protected against classical cryptanalysis, future disk compromises, and Harvest-Now-Decrypt-Later quantum adversaries.