POC global: add PQC ML-KEM to handshake as PSK #37
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
If Tailscale switches to Go 1.24 one could use |
aparcar
changed the title
This commit extends the handshake to generate a PQC-based PSK. The NIST-approved ML-KEM (formerly Kyber) is included in the initiator and responder messages to transport the encapsulation key and ciphertext, respectively. The generated shared secrets are directly injected as a pre-shared key (PSK), since PQC resilience is the intended purpose. The ML-KEM encapsulation key and ciphertext are piggybacked onto WireGuard message types 1 and 2, without altering the handshake itself. As a result, the initiation and response messages grow by about 1 kB (~10x) and the handshake takes ~5x longer (0.21s vs 0.93s[^1]), however, likely negligible, since the transported data stream is unaffected. This commit does not address PQC authentication. However, it offers a practical solution to mitigate retrospective decryption using quantum computers-namely, "store now, decrypt later" attacks. While more comprehensive approaches like "Post-quantum WireGuard"[^2] include PQC authentication and a full PQC handshake, the changes proposed here aim to be as minimal as possible, usable as soon as possible. [^1]: Naively running `go test -bench=TestNoiseHandshake -count=100` [^2]: https://eprint.iacr.org/2020/379.pdf Signed-off-by: Paul Spooren <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I recently learned about Tailscale and found this article regarding PQC. If the approach suggested here would really be taken, two new message types should be added for backwards compatibility and a new option added to
peer.golikepqcBasedPskto enable this feature for chosen peers.This commit extends the handshake to generate a PQC-based PSK. The NIST-approved ML-KEM (formerly Kyber) is included in the initiator and responder messages to transport the encapsulation key and ciphertext, respectively. The generated shared secrets are directly injected as a pre-shared key (PSK), since PQC resilience is the intended purpose.
The ML-KEM encapsulation key and ciphertext are piggybacked onto WireGuard message types 1 and 2, without altering the handshake itself.
As a result, the initiation and response messages grow by about 1 kB (~10x) and the handshake takes ~5x longer (0.21s vs 0.93s1), however, likely negligible, since the transported data stream is unaffected.
This commit does not address PQC authentication. However, it offers a practical solution to mitigate retrospective decryption using quantum computers—namely, "store now, decrypt later" attacks. While more comprehensive approaches like "Post-quantum WireGuard"2 include PQC authentication and a full PQC handshake, the changes proposed here aim to be as minimal as possible, usable as soon as possible.
Footnotes
Naively running
go test -bench=TestNoiseHandshake -count=100↩https://eprint.iacr.org/2020/379.pdf ↩