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=