From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 13 Nov 2026 10:15:51 -0800 Received: from mail-oo1-f59.google.com ([209.85.161.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xRvoU-000RZS-Sf for bitcoindev@gnusha.org; Fri, 13 Nov 2026 10:15:51 -0800 Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-7170b84e158sf1790601eaf.1 for ; Fri, 13 Nov 2026 10:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20260707; t=1794593744; x=1795198544; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to:content-type; bh=GsfS9Cfr90l8CrBjvuMB047v4fBPJzdDUXMEiWEVUM0=; b=ka0bLr8XjjkTYXHdtAuMuZLzUEcGxjkp0fd+oD3mn8BkXmCZOR5CkqDzEAQghe4xJW Eff8pqvm5ot3NEXtgHIVzuSu+QafrIXwsud57NfkzHEm90W1PqR612l+tlSjJaH24R2A 3iSJNH8FRj3hmJm9WafRxaPdHjYj/x70HpmzODnKc/9RqE5kl53jEE2nK/NzmKE7iRpK I8nV1dT9P3ZFY6CHN/Q2QHbb3lUAC7dpSX+7V5Yz3IHXzMJhyrdCAlpzTpVX7i09xUEY cszVaaVacv7SAzIwiHza8twdKNzP2jKKClB1GmrdLVBrmm1SAyxE/Ex3nZfeFS8PSZgW tC0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794593744; x=1795198544; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=GsfS9Cfr90l8CrBjvuMB047v4fBPJzdDUXMEiWEVUM0=; b=pQMoW2UYOSEXdGO8XH6SUiytoldflj9hM90huWNOlO8cLO8uOr+yx4qIVeLOsU04Cl bNH1YuZN27a1J+Fj+zv1uu7l/FJU+pnr0Om7pUrfQc+KaVHNfSPP/PN8eiltyWWW+yJR nGjg/OeA6i8TdxnGBRFrCI+yRt44l8gP0qwCk4iHIIFlT4XYIeh2n09O9FjWN5BLmvhB Z0hpwoazH9erbZbAHe8nncxiaQlU7vWzLDaVZjH/GIhKFZFKEP0hGUcfER+5EJfR6Feb 8a0fYFTqCznErAe19fUyOGUyLMlIRhZQ9ripPsJxSYinIdNj5qR8JXiAQQ/QAyzTnQVm S57Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794593744; x=1795198544; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=GsfS9Cfr90l8CrBjvuMB047v4fBPJzdDUXMEiWEVUM0=; b=KG+lQOnoesuJfX0KNpORImx4otjG2Rzi5e2kotFb//KbBzH7Ti7PQYrcLgQ28ZaAZ0 5IqEkBKE4bin+8jcuFapjxMj6RivpknanTgZN2NUOCMtG6RSwr2XyBCdpRPrfW4/Gqze 9kvQIiTArNndVYmnpXGG0KGLg6t2fB3F5DGje5ag+yiAxw21CsD2AMidMPX3GaiB55l8 ox+JP5cPlviDdaChj+Cz7chw/Qju+CideWGsBqYkk0MtAWrmXifI2lU2wtxVIQBC+khL QAfRoXW8xIoMn+s/ByR0ttx/tjBSr/MQtdflbAZTnsEqfN8PJJgX0KBQOfenCzkXG5wB qMLg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AL+hErE9DCEEytSANohK//bU58L+cNhagwWLqu98Hq4n24ZgRq09GCLwCSrJv8vY/oKd9AJbDVkXFhAJn8Z5@gnusha.org X-Gm-Message-State: APuU4Z9pCmmTXFsH4iQC13lVJ0j5lXg3LbbEGqbDj3FYlUhfNFXTV+0r 402ias0AMrGwsxqb9SB/nmIlOoY+grhI9KoOFoQ8gxf8xvFXiUL2winE X-Received: by 2002:a05:6820:351c:20b0:713:6ec9:ab7e with SMTP id 006d021491bc7-71ab4fb78c5mr1459370eaf.51.1794593744468; Fri, 13 Nov 2026 10:15:44 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdds3XvyRe9QOdhq7fVNWb4IYrv8686fPBoNDCQA81Ttwg==" Received: by 2002:a05:6820:4a09:b0:6b1:9f43:c57e with SMTP id 006d021491bc7-71ab213ebe6ls1537899eaf.0.-pod-prod-07-us; Fri, 13 Nov 2026 10:15:37 -0800 (PST) X-Received: by 2002:a05:6808:1a03:b0:56b:4351:49bd with SMTP id 5614622812f47-56e647dfc6dmr2692092b6e.52.1794593737427; Fri, 13 Nov 2026 10:15:37 -0800 (PST) Received: by 2002:a05:690c:3003:b0:8a6:990a:8ca5 with SMTP id 00721157ae682-8b4b0f55fa5ms7b3; Fri, 13 Nov 2026 09:57:23 -0800 (PST) X-Received: by 2002:a05:690c:a923:10b0:8b3:2c71:b338 with SMTP id 00721157ae682-8b4aa33e3b6mr14457587b3.82.1794592642467; Fri, 13 Nov 2026 09:57:22 -0800 (PST) Date: Fri, 13 Nov 2026 09:57:22 -0800 (PST) From: Liam Gilligan To: Bitcoin Development Mailing List Message-Id: <12a1a76d-0e27-4035-9fe8-a47524729c47n@googlegroups.com> Subject: [bitcoindev] BIP Proposal: ML-KEM Key Establishment MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_12728_1427544885.1794592642144" X-Original-Sender: liamdgilligan@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_12728_1427544885.1794592642144 Content-Type: multipart/alternative; boundary="----=_Part_12729_1701675455.1794592642144" ------=_Part_12729_1701675455.1794592642144 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_12729_1701675455.1794592642144 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

Based on discussions started by Lao= lu about post-quantum key establishment in the P2P protocol [1], I earlier = proposed a BIP that provides a mechanism for negotiating transport layer up= grades, such as key establishment or authentication [2].

The fir= st 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 secp256= k1 gives about 128 bits of security against a classical attacker. ML-KEM-51= 2 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 i= mproved attacks. ML-KEM-768 (category 3) provides that margin and is the pa= rameter 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 e= ncapsulation key (1184 bytes) and ciphertext (1088 bytes) as defined by FIP= S 203 [3]. The advertiser will have the option to omit its encapsulation ke= y when advertising ML-KEM support, to avoid the bandwidth cost of sending i= t to a peer that may not support ML-KEM. If the advertiser omits it, the se= lector 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 ke= ys beginning with its next packet. The party that sends the encapsulation k= ey sends nothing further until it receives the ciphertext, then rekeys, so = its next packet is also the first under the new keys.

A node dis= connects if the encapsulation key it receives fails the input check FIPS 20= 3 requires. ML-KEM does not guarantee success: there is about a 2^-165 chan= ce 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 ciphertex= t, as they are already encrypted under BIP-324 and therefore appear random = on the wire.

Let me know your thoughts, particularly on the para= meter set and on whether the advertiser should send its encapsulation key b= y default.

- Liam

[1] https://groups.google.com/g/bit= coindev/c/n_5WuKVYqwI/
[2] https://groups.google.com/g/bitcoindev/c/Lb= TSN08fYlM
[3] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf=
[4] https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#el= ligatorswift-encoding-of-curve-x-coordinates
[5] https://csrc.nist.gov= /csrc/media/Events/2025/workshop-on-guidance-for-kems/documents/papers/keme= leon-paper.pdf

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/12a1a76d-0e27-4035-9fe8-a47524729c47n%40googlegroups.com.
------=_Part_12729_1701675455.1794592642144-- ------=_Part_12728_1427544885.1794592642144--