Replacing X25519 with ML-KEM in WireGuard

Why This Matters Now

WireGuard is the gold standard for modern VPNs. It replaced OpenVPN's sprawling C codebase with ~4,000 lines of clean, audited code and a single cryptographic handshake built on the Noise protocol framework. Every session starts with an IKpsk2 pattern exchange that relies on X25519 Diffie-Hellman for forward secrecy.

X25519 is strong against classical computers. It is not strong against a cryptographically-relevant quantum computer running Shor's algorithm. The threat is not theoretical — it's a "harvest now, decrypt later" problem. Adversaries are storing encrypted VPN traffic today, planning to decrypt it when quantum hardware matures. For government networks, defence infrastructure, and classified communications, that risk is unacceptable.

WireGuard's Handshake — What We're Replacing

WireGuard's handshake is described by the Noise IKpsk2 pattern. In plain terms, the initiator and responder each hold a static keypair and exchange ephemeral keys to establish a shared session secret. The relevant steps:

Initiator                         Responder
─────────                         ─────────
Generate ephemeral keypair (e_i)
e_i_pub ──────────────────────►
                                  Generate ephemeral keypair (e_r)
                             ◄── e_r_pub
Both compute:
  shared_1 = DH(e_i, e_r)         (ephemeral-ephemeral)
  shared_2 = DH(e_i, s_r)         (initiator-ephemeral × responder-static)
  shared_3 = DH(s_i, e_r)         (initiator-static × responder-ephemeral)

Session key = KDF(shared_1 || shared_2 || shared_3 || psk)

X25519 makes this work because both parties can compute the same shared secret from each other's public keys. ML-KEM is a Key Encapsulation Mechanism — it works differently. Only the encapsulator (initiator) generates a ciphertext; the decapsulator (responder) recovers the shared secret from it. This means a direct substitution breaks the symmetry of Noise.

The Hybrid Approach

A clean swap from X25519 to ML-KEM alone would require forking Noise's handshake logic. A safer, standards-aligned approach is a hybrid KEM: run X25519 and ML-KEM in parallel, then combine their shared secrets with a KDF. This gives you:

Classical security: if ML-KEM has an undiscovered flaw, X25519 still protects you.
Quantum security: if X25519 is broken by a quantum computer, ML-KEM still protects you.

Hybrid shared secret = HKDF(
  X25519_shared_secret || ML-KEM_shared_secret,
  salt = "WireGuard-PQC-Hybrid-v1"
)

Key Size Impact

ML-KEM's keys are substantially larger than X25519. This is the most visible compatibility cost:

The handshake packets grow from ~148 bytes to ~2.4 KB — a one-time cost at session setup. Data packets after the handshake are unchanged. For long-lived tunnels this amortizes quickly; for extremely high-frequency short sessions (think IoT keepalives) it's worth measuring.

Implementation Sketch

WireGuard's kernel module is not the right place to prototype this. A userspace implementation — using Go's wireguard-go and the mlkem768 package — lets you validate the handshake logic before touching kernel code.

package handshake

import (
    "crypto/ecdh"
    "golang.org/x/crypto/hkdf"
    "crypto/sha256"
    "filippo.io/mlkem768"
)

// HybridHandshake combines X25519 and ML-KEM-768 shared secrets.
func HybridSharedSecret(
    x25519Secret []byte,
    mlkemSecret  []byte,
) ([]byte, error) {
    combined := append(x25519Secret, mlkemSecret...)
    h := hkdf.New(sha256.New, combined, nil,
        []byte("WireGuard-PQC-Hybrid-v1"))
    out := make([]byte, 32)
    _, err := h.Read(out)
    return out, err
}

// Initiator side: encapsulate against responder's ML-KEM public key.
func Encapsulate(responderPK *mlkem768.PublicKey) (
    ciphertext []byte, sharedSecret []byte, err error,
) {
    return mlkem768.Encapsulate(responderPK)
}

// Responder side: recover shared secret from ciphertext.
func Decapsulate(sk *mlkem768.DecapsulationKey, ct []byte) ([]byte, error) {
    return mlkem768.Decapsulate(sk, ct)
}

Benchmark Results

Tested on an ARM Cortex-A72 (Raspberry Pi 4) — a realistic embedded/edge VPN node:

The hybrid handshake is ~3.5× slower than X25519 alone. In absolute terms, 2.1 ms is still imperceptible for a human-initiated connection. For automated tunnel re-keying (default WireGuard re-key interval: 3 minutes), this is completely negligible.

What's Not Solved Yet

This hybrid approach handles key exchange. It does not address:

Identity authentication: WireGuard uses Ed25519 for static key authentication. Ed25519 is also vulnerable to quantum attacks. A fully quantum-safe WireGuard would also need to replace Ed25519 with ML-DSA (FIPS 204).

MTU fragmentation: The larger handshake packets can exceed common MTUs (1500 bytes) and trigger fragmentation on constrained links. This needs careful handling in the packet framing layer.

Kernel integration: Shipping this into WireGuard's kernel module requires upstream agreement on the handshake format. There is active IETF work on a post-quantum Noise extension — that's the right place to standardize the wire format.

Takeaway

Replacing X25519 with ML-KEM in WireGuard is not a direct substitution — the KEM model and DH model are fundamentally different. A hybrid parallel approach is the safe path: you preserve classical security, add quantum resistance, and take a modest ~3.5× handshake overhead that vanishes in any realistic long-lived tunnel. The bigger unsolved problem is authentication, not key exchange.

If you work on critical infrastructure — government networks, military systems, financial clearing — start your PQC transition now. The "harvest now, decrypt later" clock is already running.

The author implements WireGuard-based VPN infrastructure at ADRIN, Department of Space, Government of India, and researches post-quantum cryptographic integration for mission-critical systems.