Export noise primitives for additional "chain key ratcheting"

Paul Spooren <[email protected]> Tue, 31 Mar 2026 22:14:51 +0200
Newsgroups com.zx2c4.lists.wireguard
Message-ID <[email protected]>
Hi,

I=E2=80=99m looking into hardening WireGuard against quantum computers, =
specifically how to extend the Noise-based handshake.=20

A bit of background, while PSK injection with external daemons for =
forward secrecy, exists, that=E2=80=99s extra software running, exposing =
extra ports etc. Modifying a Rust/Go implementation is easier than the =
Kernel, but my background is running things on WiFi routers, so Kernel =
is preferred. That said, I=E2=80=99d like to extend the current =
WireGuard message format and attach PQC without exceeding the IPv6 MTU =
of 1280 bytes. In literature I don=E2=80=99t find definitive a PQC =
handshake standard, however combining ML-KEM512 for forward secrecy and =
McEliece460896 for static long-term keys does exist in practice[1] and =
fits into WireGuard init and response messages. Alternatively, sntrup653 =
could be used for forward secrecy without PQ authentication, similar to =
Signal's PQXDH[2]. Possibly new primitives/schemes are developed, with =
smaller public keys and ciphertexts.=20

Just today I read an email about ML-KEM and the Kernel; none of these =
cryptographic primitives are (to my knowledge) part of the Linux Kernel, =
making a =E2=80=9Cnew=E2=80=9D protocol version of WireGuard more =
difficult to implement and further out in the future.

I wondered if WireGuard could export some of the noise primitives like =
mix_hash and mix_key to allow =E2=80=9Cone way=E2=80=9D (ratchet) =
modifications of the chaining key and =E2=80=9Cappend only" bytes to the =
outgoing packet (PQ pubkey, ciphertext). After appending bytes, =
WireGuard takes over again and calculates the MAC, proceeding as usual. =
The "ratcheting=E2=80=9D Kernel module would work similar to the =
existing PSK approach, it adds additional data to the chaining key, =
however it can=E2=80=99t downgrade it (except crashing the Kernel). =
Another approach could be to add netlink handling for an active daemon, =
this would at least reduce the open ports and network complexity.=20

Yet another way to have PQ WireGuard could be to produce one's own =
modules like WolfGuard did the recently[3] with AES/FIPS, however I =
thought to ask anyway.

Thanks,
Paul

[1]: https://rosenpass.eu/docs/rosenpass-project/whitepaper/
[2]: https://signal.org/docs/specifications/pqxdh/
[3]: https://github.com/wolfSSL/wolfGuard=