Export noise primitives for additional "chain key ratcheting"
Paul Spooren
mail at aparcar.org
Tue Mar 31 20:14:51 UTC 2026
Hi,
I’m looking into hardening WireGuard against quantum computers, specifically how to extend the Noise-based handshake.
A bit of background, while PSK injection with external daemons for forward secrecy, exists, that’s 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’d like to extend the current WireGuard message format and attach PQC without exceeding the IPv6 MTU of 1280 bytes. In literature I don’t 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.
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 “new” 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 “one way” (ratchet) modifications of the chaining key and “append 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” Kernel module would work similar to the existing PSK approach, it adds additional data to the chaining key, however it can’t 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.
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
More information about the WireGuard
mailing list