From: Liam Gilligan <liamdgilligan@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] BIP Proposal: ML-KEM Key Establishment
Date: Fri, 13 Nov 2026 09:57:22 -0800 (PST) [thread overview]
Message-ID: <12a1a76d-0e27-4035-9fe8-a47524729c47n@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3363 bytes --]
Hi everyone,
Based on discussions started by Laolu about post-quantum key establishment
in the P2P protocol [1], I earlier proposed a BIP that provides a mechanism
for negotiating transport layer upgrades, such as key establishment or
authentication [2].
The first feature I'd like to specify for it is ML-KEM key establishment,
so that P2P traffic recorded today cannot be decrypted by a future quantum
attacker.
I propose we use the ML-KEM-768 parameter set. ECDH on secp256k1 gives
about 128 bits of security against a classical attacker. ML-KEM-512 targets
a comparable level (NIST category 1), but given the youth of the assumption
ML-KEM relies on, more margin should be given to hedge against improved
attacks. ML-KEM-768 (category 3) provides that margin and is the parameter
set NIST recommends by default. ML-KEM-1024 (category 5) gives more still,
but at the cost of larger encapsulation keys and ciphertexts.
The feature will simply consist of payloads directly containing the
encapsulation key (1184 bytes) and ciphertext (1088 bytes) as defined by
FIPS 203 [3]. The advertiser will have the option to omit its encapsulation
key when advertising ML-KEM support, to avoid the bandwidth cost of sending
it to a peer that may not support ML-KEM. If the advertiser omits it, the
selector sends an encapsulation key instead, and the advertiser responds
with its ciphertext in a subsequent feature packet.
The new keys are derived from both the existing BIP-324 shared secret and
the ML-KEM shared secret, so the connection is at least as secure as it is
today. The party that sends the ciphertext rekeys immediately, and encrypts
under the new keys beginning with its next packet. The party that sends the
encapsulation key sends nothing further until it receives the ciphertext,
then rekeys, so its next packet is also the first under the new keys.
A node disconnects if the encapsulation key it receives fails the input
check FIPS 203 requires. ML-KEM does not guarantee success: there is about
a 2^-165 chance of decapsulation failure. This is unreachable in practice,
and needs no handling of its own, as the peers would derive different keys
and the next packet would fail to decrypt.
No encoding like ElligatorSwift [4], such as Kemeleon [5], is required for
the encapsulation key or ciphertext, as they are already encrypted under
BIP-324 and therefore appear random on the wire.
Let me know your thoughts, particularly on the parameter set and on whether
the advertiser should send its encapsulation key by default.
- Liam
[1] https://groups.google.com/g/bitcoindev/c/n_5WuKVYqwI/
[2] https://groups.google.com/g/bitcoindev/c/LbTSN08fYlM
[3] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
[4]
https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#elligatorswift-encoding-of-curve-x-coordinates
[5]
https://csrc.nist.gov/csrc/media/Events/2025/workshop-on-guidance-for-kems/documents/papers/kemeleon-paper.pdf
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/12a1a76d-0e27-4035-9fe8-a47524729c47n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3731 bytes --]
reply other threads:[~2026-11-13 18:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12a1a76d-0e27-4035-9fe8-a47524729c47n@googlegroups.com \
--to=liamdgilligan@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox