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.