From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 09 May 2026 02:39:29 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wLe9c-0001H1-Ul for bitcoindev@gnusha.org; Sat, 09 May 2026 02:39:29 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-40f25e55f20sf3950636fac.0 for ; Sat, 09 May 2026 02:39:23 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1778319553; cv=pass; d=google.com; s=arc-20240605; b=NOfM2xxnXXmc9ZvY3b3b4BkWaKPIqpf3Hp+6fz4QRdq8QwVetDtYZ98fB7p7hISg6v OKI2fp8nsnDmVVe+jvOun+V9mefS5ooNxyE98JFh2BVKH9Dh+5RBMQAWmnu5Khpp0aV6 0cN4b9zjScKNlt8tUTofsGbvnSS0/pIF5AtpCl8s137WtEtugdmyHS4sQQqdM2plnvTw v+jl9wbEqKXeT3/rWdXr1exR4YfvPNRmYpKeoeRD4mnbZOR4SUcYIA2OfcUTN0MxvM1I AwahtuIUvCQtLnQriqDgjeDKag2N4rQXRH34IGEYSPvZmcFMAWVA/0+Y5cR0zX1lbp82 DNDg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=RJfA1WtlE5nPkrNx71GM/WpVNF+N3hFMp8w4AJxJXr0=; fh=Nz6DQaZVo78CjGF6NrhsKfGrdb282jIajOz5WpxAZZI=; b=bv1IOwcLFkTUnrWD5KjMevRORGNoyu6xah0i6qJCJrPpwv0geiipd1OMPEpM12PjZb EAxtbjOiZ/p9nBa8q6nZc4V2xKxRaFVSwBt/OoAnpblfxOapVcNf/cLs24NEoFdaOafS Q9g3WG1J7s0oU1B9kGqm1vk4G0KkpPkGEw6zUjsGNL22uI0T2K3ZtCWG8TXqdFLaEZIV 9ahpTSQPiUqIKxhEy2WFGAXwUfWbQMVF8ZBc+Op0rfHhqbqKFhSTc69IGb9NkUeViDXd EpLZ21OIdiAqSqUZbGydLHoZz19L+oq+bRnKJVzObKDxPe0mXUn4Qv36JckM0O3J3Gz/ SXOg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=txjr2vc4szcdvnw3thvmtoarle.protonmail header.b=MC2XW+cs; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1778319553; x=1778924353; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=RJfA1WtlE5nPkrNx71GM/WpVNF+N3hFMp8w4AJxJXr0=; b=sZaK0adyT07fp9fPQKBjFPIoKvV3O/AxTWpnI1nr/USMZ7KuHYIQc3L7lp0DgyA714 CSGrONYaJXCbTz7jkEfsJ7uJGHnVkHg+qIWaYiFXjAIDUiDjlO6WLbUjtvt+dLmApVUG Y3atGLBd7Zveds1cWzbWoWIRRKGRuhoWk3MJiUZUZqm0a2qEDfcpWWHACQnqNngals4z 2b+MByAQEXJeZqZw54IgyLekqn2dAHm/dKr7b/tbOlUt+ddhwzihUCMiaWFfRkdqwpUH OckqxricyxO28NszBhjIvOSxEIHIvun5I5R0srUxamjq1NOl+uYtTgVNxsOma2LpjO5C 1eVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778319553; x=1778924353; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RJfA1WtlE5nPkrNx71GM/WpVNF+N3hFMp8w4AJxJXr0=; b=pH3aP0cQNUOWBudWsDiuCk9XASo+m0xk2h/8JUZ+dRQTr56g7zd3iCVI+0TLaO4bB7 jY5JASivMqoWA2kw94ZcZBu6MgO2Uzt7I/zxd9M9Rubpk7zvkh7OAD4e17L3NVibd1Ef US0JP4NwK9EUjL4EGPh6MCTLWgr2BFqW5J+GOvnXkGB0Eu3vPONuNMNw3gG7jtEeVPBD dpkZn2kFmaU1QOzGh/hOkAVrV7E0t6ADlbscef5vAz3U+Zv4quKWSHQVhjb/kxc10NUc ThQeM2SALeCKCkV+IT6z/d4ABazh8rprB09rnPkqD8zCxB0qg6YtL3DUOLxQeoLRcrAT blnQ== X-Forwarded-Encrypted: i=2; AFNElJ8yOPmIP5XB2NDt6CR3F+NPSzdmffmDPQ6aBvu5F7d7alemjJPfmyGQlyY/SHgshOATLfsgy7Ls2Ioq@gnusha.org X-Gm-Message-State: AOJu0Yzmp22ZwV3QSUAENaHm2zLk/pPSXYg6IC3LE7ST7cPlY+nntHeW DtShnrtGUXUTNV7YjitYB/Hu/ip4eDfICWdoDGllZTdSSSku4H+oF6Rj X-Received: by 2002:a05:6870:15c6:b0:430:27a4:e9cb with SMTP id 586e51a60fabf-43556b9dfbemr3683264fac.13.1778319553105; Sat, 09 May 2026 02:39:13 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMMkvLP0f8ga+6b+Bkclpzu6n7dsKdTsGW49mlWlykfNmw==" Received: by 2002:a05:6870:718e:b0:42c:22ed:f980 with SMTP id 586e51a60fabf-4358f9c6d7cls136689fac.0.-pod-prod-01-us; Sat, 09 May 2026 02:39:08 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/WeIABZmIhtrfzWtOGkfDbzEm6/HIlWSBAXnxolBpBl1QcldqgIg0W4W2gtMXFRtZ7hYzh5/PCVyjJ@googlegroups.com X-Received: by 2002:a05:6808:e687:b0:47b:d07b:ec9b with SMTP id 5614622812f47-4807fd390bamr2757331b6e.24.1778319548706; Sat, 09 May 2026 02:39:08 -0700 (PDT) Received: by 2002:a05:6402:a58c:20b0:672:bd1b:222f with SMTP id 4fb4d7f45d1cf-67ec3819ae4msa12; Fri, 8 May 2026 20:23:26 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+bL5qTGiBzxsx3pEj84bZoYwFD/3vkUSMSyFw6LKMaCIwarx5nPhxfdilczkhUODvDICDo5rp/R1JJ@googlegroups.com X-Received: by 2002:a05:6402:a544:20b0:67c:fb8e:41c8 with SMTP id 4fb4d7f45d1cf-67e0efb1682mr3592515a12.12.1778297004906; Fri, 08 May 2026 20:23:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778297004; cv=none; d=google.com; s=arc-20240605; b=lyMW1BiAS+DsXRm4lHejRQohGvHRhJMB6eigTI4kQ/KAcFWVArTuhMLpSeT1zeJnzG /kfdPXhDozihvVkWrQ+eRWzXXdd3ef8M3R6V3/VN8VxRIznwo3DPOnubbni1OUlCrWm0 OpWft8V3aqRQgrspU1s7c3yKYCfzPBdcylV0Zu+UkApWhgD2XdjCG8SHPzQCVopSVDKI UzWeumKCE2q5KGtLbu44bBhCnwwv5wV9K+4BLBxDxy/YKQyvovGp1EaPterAsHFjMYGP /OY5uyLZxg5dVP8xxcqu77ePrbb6qN1uTsYDrz27Ph9A0VCsa2wYjlj0hBwbGDScdolg bxXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=9nOdBEuROR03LX1yukPTdErrtehwIv3mXoNZf9sDVe8=; fh=JRz+axGi8dlp8x/Igc80lZ3Z7m7umVGO9kcwu8JX5X8=; b=ZDLpjKQ6on9/8Sb5ZKJSlQsIXuCUMRQJZxSiyxbmodSIUc2cFz1ZSOEvqxgTjOt63X Nm9Jgy8v0NeZoObfdy5QD3dqKDgp5/h/FhvFs7a6JAiZ67DNJZIfjqlaYwTisXwsZVpa XyjELO+rfhmTaLbLwa3wRArdCmAU/JjnrUXS0D3/3hY0DLn+uAg3R3EAU5jJG3TjE5zf ixvmPTVsCCkLeV4uV1lrAKPt7faOq6bji+kxhRPxvcdTbX+CkixXaj3F+yKkfeG4eudJ 66Mo1cyakqPdpSq/LIiKRhcblLZpZsz78bW6dk9GfCkPhcRWjVU4du7I8QncrhAM2SJs Rjyg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=txjr2vc4szcdvnw3thvmtoarle.protonmail header.b=MC2XW+cs; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106102.protonmail.ch (mail-106102.protonmail.ch. [79.135.106.102]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-67ef0e2749dsi56076a12.6.2026.05.08.20.23.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2026 20:23:24 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) client-ip=79.135.106.102; Date: Sat, 09 May 2026 03:23:18 +0000 To: Jonas Schnelli From: "'conduition' via Bitcoin Development Mailing List" Cc: Olaoluwa Osuntokun , Ethan Heilman , Bitcoin Development Mailing List Subject: Re: [bitcoindev] A Post-Quantum Path for BIP 324 Message-ID: In-Reply-To: References: <547ADFCA-2BB1-4E16-A26A-C92262EBBD84@gmail.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 4d6db65d8497d2f52c3752cc24b19b1bd3b297aa MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------dd4b72cee60ba2b95036e3b59552e6c820d50f86d08c00b14ad28cf27e10226c"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=txjr2vc4szcdvnw3thvmtoarle.protonmail header.b=MC2XW+cs; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------dd4b72cee60ba2b95036e3b59552e6c820d50f86d08c00b14ad28cf27e10226c Content-Type: multipart/mixed;boundary=---------------------7b74a2ef071299329c0e86f53f07dbbb -----------------------7b74a2ef071299329c0e86f53f07dbbb Content-Type: multipart/alternative;boundary=---------------------640d12b7438260bda61005e47ede9a9e -----------------------640d12b7438260bda61005e47ede9a9e Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Oopsie, I just saw Laolu's footnote #4 about ignoring isogeny crypto. Guess= I should learn to read better :P regards, conduition On Friday, May 8th, 2026 at 8:21 PM, conduition wrot= e: > Hi all, >=20 > I'm not well-versed in the P2P network transport protocol or BIP324, so I= 'm not well-qualified to give feedback on the details of this idea. But I d= id want to chime in on this statement: >=20 >=20 > > One thing worth noting is that AFAICT, so far in the NIST PQC world [4]= , there is=C2=A0no known non-interactive key exchange protocol like we enjo= y today with ECDH. IIUC, the reason is that lattice based schemes derived f= rom the LWE [3] problem, whose security is predicated on using "noise" to h= ide a secret value. For these cryptosystems, usually a type of "hint" is se= nt to make everything work out nicely like in ECDH. However, in the stricte= r non-interactive setting=C2=A0(no messages sent), this doesn't map cleanly= .=C2=A0 >=20 >=20 >=20 > It's important to emphasize this only considers the NIST-standardized KEM= s. If we zoom out to the broader ecosystem of PQ PKE candidates, there are = several options for non-interactive key exchange systems that'd be a drop-i= n replacement for ECDH. >=20 >=20 > For instance, oriented isogeny-based systems like CSIDH [1] [2] permit th= is kind of construction. Both parties publish a short (64 to 128 byte) pubk= ey and can perform key exchange as soon as they've seen the peer's pubkey, = no additional messages required. The down side of CSIDH is that it's quite = slow, so it is most useful when pubkeys are static or otherwise don't chang= e much. There has been a lot of work done with new faster schemes=C2=A0[3] = or speeding up CSIDH with better implementations=C2=A0[4] but still key exc= hange can take a good few dozen milliseconds.=C2=A0 >=20 >=20 > In general, any post-quantum-secure commutative group action scheme allow= s non-interactive key exchange. CSIDH is just one such example, and I'm sur= e there are and will be others. >=20 > Being unversed in BIP324 as yet, I'm not sure how crucial this non-intera= ctivity property is to the protocol. If it's not a big deal, then I'd gladl= y toss my hat in for lattices and a hybridized ML-KEM construction, given s= o much of the internet is already migrating to this. It makes sense to foll= ow standards if we can. Going full-TLS would probably be overkill IMO - It = is designed for a very different (centralized) PKI architecture and would b= uy us a ticket for a train we probably don't want to ride. >=20 > Maybe there's a more applicable standard, a la Noise/Wireguard? For a pos= sible implementation reference, see [5]. Otherwise rolling our own standard= seems like the way to go, especially if we can do so in a way that is reus= able for other use-cases beyond Bitcoin. >=20 > Also, if we go with a hybrid scheme, we should have clear migration paths= to transition to either pure PQC (if a CRQC appears and breaks ECDH, we mi= ght as well discard it), or back to classical ECDH (if CRQCs turn out to be= impossible). >=20 >=20 > regards, > conduition >=20 >=20 > [1]:=C2=A0https://csidh.isogeny.org/ > [2]:=C2=A0https://eprint.iacr.org/2018/383 > [3]:=C2=A0https://eprint.iacr.org/2025/1098.pdf > [4]:=C2=A0https://ctidh.isogeny.org/ctidh-20210513.pdf > [5]:=C2=A0https://github.com/jmlepisto/clatter >=20 >=20 >=20 >=20 >=20 > On Thursday, May 7th, 2026 at 1:45 AM, Jonas Schnelli wrote: >=20 > > Thanks for writing this up Laolu. > >=20 > > I think option 1 (classical-then-PQ-upgrade) is probably the right path= , mostly because it keeps the byte-0 pseudorandomness property without need= ing Kemeleon or any new obfuscation primitive. > >=20 > > If the ML-KEM exchange happens inside the already-established v2 ChaCha= 20Poly1305 channel, then to a present-day classical observer the bytes shou= ld still look random,... the inner PQ handshake is just more ciphertext. A = future QC adversary doing harvest-now-decrypt-later would break the outer E= CDH eventually, but I think they'd then still have to break ML-KEM-768 to g= et the v3 transport keys, which is kind of the whole point. So we'd probabl= y get hybrid security against the QC threat and also keep the property that= today's wire bytes are indistinguishable from random. > >=20 > > That said, I'm not sure how far we should really take the pseudorandomn= ess argument,... traffic shape (packet sizes, timings, query/response patte= rns) probably already reveals quite a bit about what's going on, so the byt= e-content randomness is only one part of the picture. > >=20 > > The extra round trip is probably fine given how long Bitcoin P2P connec= tions live. The DoS angle you flagged might also be smaller in option 1, si= nce the responder still commits after 64 bytes and not after a 1184-byte ML= -KEM key,... though I haven't thought hard about wether there are other DoS= vectors the inner upgrade introduces. > >=20 > > On Ethan's TLS 1.3 suggestionm,... I don't think it really fits. Apart = from the dependency cost (which we deliberately kept low in BIP 324), TLS h= as it's own fingerprint, which would probably undo the censorship-resistanc= e angle. And it bundles authentication with encryption, which we explicitly= decoupled. > >=20 > > One thing worth looking at: OpenSSH (whose chacha20-poly1305 constructi= on we drew from originally) shipped mlkem768x25519-sha256 as default in 10.= 0 last year, and they just concatenate-and-hash the two shared secrets. The= ir threat model doesn't care about pseudorandomness so they can send ML-KEM= material in the clear, but the combiner shape is probably a reasonable ref= erence for ours. > >=20 > > /jonas > >=20 > >=20 > > > On May 6, 2026, at 12:15=E2=80=AFPM, Olaoluwa Osuntokun wrote: > > >=20 > > > Hi Ethan,=C2=A0 > > >=20 > > > That's a great question.=C2=A0 > > >=20 > > > First, I don't speak for Bitcoin Core by any means (btcd has also imp= lemented > > > BIP 324 FWIW). Based on past observed behavior, they typically prefer= to keep > > > dependencies slim. Many years ago there was a concerted push to remov= e openssl > > > as a dependency from the project. So I would imagine the idea of roll= ing out > > > full blown TLS 1.3 might encounter some resistance. > > >=20 > > > In terms of cryptography, BIP 324 as defined uses secp256k1. TLS 1.3 = as > > > specified doesn't support secp256k1 within the set of supported ciphe= r suites. > > >=20 > > > If ensuring that BIP 324 continues to implement an oblivious KEM is a= key > > > requirement, then TLS 1.3 doesn't fit the bill. > > >=20 > > > Regarding a hybrid PQ KEM, there exists an IETF to add a new key agre= ement > > > suite to TLS 1.3:=C2=A0https://datatracker.ietf.org/doc/draft-ietf-tl= s-ecdhe-mlkem/. > > > Only secp256+384(r1) and x25519 are supported as elliptic curves in t= his draft. > > >=20 > > > One additional aspect is that today BIP 324 doesn't implement authent= ication at > > > all, you only get confidentiality. TLS 1.3 would mean introducing cer= tificates > > > in some fashion, thereby coupling concerns from the original PoV of B= ip 324. > > >=20 > > > BIP 324 also includes as section in the BIP detailing the rationale o= f BIP 324 > > > over a more general purpose protocol (mentions some of the points abo= ve): > > > https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#:~:tex= t=3DWhy%20not%20use%20a%20general%2Dpurpose%20transport%20encryption%20prot= ocol%3F. > > >=20 > > >=20 > > > -- Laolu > > >=20 > > > On Tue, May 5, 2026 at 2:18=E2=80=AFPM Ethan Heilman wrote: > > >=20 > > > > Thanks Laolu for thinking through making PQ BIP 324 and writing thi= s up. > > > >=20 > > > > Reading through what you wrote made me what wonder, why not use thi= s as an opportunity to move to TLS 1.3? > > > >=20 > > > > What's the case against using TLS 1.3 for PQ P2P connection encrypt= ion? Is there some functionality that TLS 1.3 is lacking that we really wan= t?=C2=A0 Is the case against solely to not have TLS 1.3 as a complex depend= ency in bitcoin-core? > > > > The advantages of TLS 1.3: > > > >=20 > > > > 1. Make Bitcoin P2P connections blend in with all the other TLS con= nections. This isn't strong privacy, you can distinguish TLS encrypted Bitc= oin traffic via timing and size, but it reduces accidents where a firewall = sees an unknown protocol and blocks it. > > > >=20 > > > > 2. Use of QUIC for faster relay, oblivious HTTP and QUIC tunnels-in= -tunnels for private relay and similar protocols. > > > > 3. Lots of eyeballs on TLS 1.3, we don't need to build or maintain = it. > > > >=20 > > > >=20 > > > > On Tue, May 5, 2026, 00:41 Olaoluwa Osuntokun w= rote: > > > >=20 > > > > > Hi y'all,=C2=A0 > > > > >=20 > > > > > In case you weren't already tired of all the recent dev list chat= ter re post > > > > > quantum cryptography, here's another! > > > > >=20 > > > > > When the topic of Bitcoin transitioning to a post quantum world i= s brought up, > > > > > the discussion typically focuses on the consensus layer re swappi= ng out > > > > > vulnerable signature schemes. However, the consensus layer isn't = the only area > > > > > of Bitcoin that relies in cryptography that would be broken in th= e face of a > > > > > powerful quantum computer! That's right, I'm talking about BIP 32= 4, the peer to > > > > > peer encryption BIP for Bitcoin. > > > > >=20 > > > > > Like everything else on the Internet today, BIP 324 uses ECDH to = allow two > > > > > connecting peers to derive a shared secret known only to them, wh= ich is then > > > > > used to encrypt all traffic between them. As ECDH relies on Ellip= tic Curve > > > > > cryptography, a future quantum computer would be able to eavesdro= p on a p2p > > > > > handshake transcript, then derive the underlying private keys to = the ephemeral > > > > > ECDH public key, permitting it to decrypt all traffic. It's actua= lly worse than > > > > > that, as today adversaries can collect all encrypted p2p Bitcoin = traffic, with > > > > > the hope of being able to decrypt it all at a future date. This i= s commonly > > > > > referred to as the: "harvest, decrypt later" (HNDL) strategy [11]= . > > > > >=20 > > > > > Compared to a consensus change, which requires widespread market = agreement, and > > > > > coordination to achieve, upgrading BIP 324 to be post quantum res= istant is a > > > > > much lower hanging fruit worthy of pursing immediately. > > > > >=20 > > > > > Last week I starting thinking a bit about this topic, brushing up= on the latest > > > > > literature/techniques, and stumbled onto a few key design questio= ns. The goal > > > > > of this post isn't to propose a new concrete p2p encryption BIP, = instead I want > > > > > to start discussion on the various design tradeoffs that came up = as I was > > > > > researching this p2p encryption transition. > > > > >=20 > > > > > ## PQ BIP 324 Design Questions > > > > >=20 > > > > > 1. Do we want to pursue a hybrid KEM (key encapsulation mechanism= ), or go with > > > > > =C2=A0 =C2=A0a pure PQ KEM? > > > > >=20 > > > > > 2. Is it still a key requirement that the initial handshake be > > > > > =C2=A0 =C2=A0indistinguishable from a random byte string? > > > > >=20 > > > > > =C2=A0 =C2=A02a. If yes to the above, then should we go with clas= sical-then-pq-upgrade, > > > > > =C2=A0 =C2=A0or a one shot hybrid oblivious KEM. > > > > >=20 > > > > >=20 > > > > > ## A Brief Intro to KEMs + ML-KEM > > > > >=20 > > > > > First, let's introduce the new primitive we have to work with: ML= -KEM > > > > > (Module-Lattice-Based Key-Encapsulation Mechanism) [1][2]. As it = says on the > > > > > tin, ML-KEM is a lattice based Key-Encapsulation Mechanism. The p= hrase KEM > > > > > might sound unfamiliar with those comfortable with ECDH, but ECDH= is actually a > > > > > KEM itself. > > > > >=20 > > > > > A KEM has 3 algorithms: > > > > > =C2=A0=C2=A0* KeyGen() -> {sk, pk} > > > > > =C2=A0 =C2=A0 =C2=A0* Generates a public/private secret key pair > > > > >=20 > > > > > =C2=A0=C2=A0* Encaps(pub) -> {secret, capsule} > > > > > =C2=A0 =C2=A0 =C2=A0* Generates a new secret value, and a "capsul= e", which only the holder of > > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0pub can use to obtain the secret value= . > > > > >=20 > > > > > =C2=A0=C2=A0* Decaps(priv, capsule) -> secret > > > > > =C2=A0 =C2=A0 =C2=A0* Uses the private key to extract the secret = from the capsule > > > > >=20 > > > > >=20 > > > > > If you squint a bit, then you'll see that ECDH is a KEM, and a ra= ther elegant > > > > > one at that: > > > > > =C2=A0=C2=A0* KeyGen() -> {k, k*G} > > > > > =C2=A0 =C2=A0 =C2=A0=C2=A0* Normal EC key generation.=C2=A0 > > > > >=20 > > > > > =C2=A0=C2=A0* Encaps(pub) -> {capsule =3D x*G, secret =3D pub*x} > > > > > =C2=A0 =C2=A0 =C2=A0=C2=A0* The core ECDH routine. The ephemeral = public key is actually the > > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"capsule". The resulting secret = is the ECDH output with the remote > > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0party's KEM public key and the l= ocal secret. > > > > >=20 > > > > > =C2=A0=C2=A0* Decaps(priv, capsule) -> secret =3D priv * capsule > > > > > =C2=A0 =C2=A0 =C2=A0=C2=A0* The receiver completes the key exchan= ge using the ephemeral public key > > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0and their own private key. > > > > >=20 > > > > > ECIES is another flavor of EC based KEM. > > > > >=20 > > > > > One thing worth noting is that AFAICT, so far in the NIST PQC wor= ld [4], there is > > > > > no known non-interactive key exchange protocol like we enjoy toda= y with ECDH. > > > > > IIUC, the reason is that lattice based schemes derived from the L= WE [3] > > > > > problem, whose security is predicated on using "noise" to hide a = secret value. > > > > > For these cryptosystems, usually a type of "hint" is sent to make= everything > > > > > work out nicely like in ECDH. However, in the stricter non-intera= ctive setting > > > > > (no messages sent), this doesn't map cleanly. > > > > >=20 > > > > > As a result, ML-KEM looks more like a hybrid encryption protocol = (Alice > > > > > encrypts a shared secret to bob using asymmetric lattice crypto). > > > > >=20 > > > > > ## To Hybrid KEM, Or Not to Hybrid KEM > > > > >=20 > > > > > This brings us to our first design question.... > > > > >=20 > > > > > Should we use a hybrid KEM or a pure post quantum one?=C2=A0 > > > > >=20 > > > > > A hybrid KEM would keep the existing ECDH, _also_ do ML-KEM, then= securely > > > > > combine (there's some subtlety there, see [6][7]) the resulting i= n a > > > > > final secret value for encryption. A hybrid KEM is attractive as = an encryption > > > > > channel derived from such a KEM is secure if _any_ of the combine= d schemes are > > > > > secure. This permits schemes to hedge a bit, as hey, maybe the PQ= stuff is > > > > > actually broken in the future but ECDH isn't. If it's the other w= ay around, > > > > > then your encryption scheme is still secure. > > > > >=20 > > > > > ### Pure ML-KEM P2P Encrypted Handshake > > > > >=20 > > > > > If we opt to not use a hybrid scheme, then the Elligator layer ca= n be dropped > > > > > all together. Instead, the 1.1 KB (ML-KEM-768) encapsulation keys= are sent, > > > > > keeping the trailing garbage+terminator in tact.=C2=A0 > > > > >=20 > > > > > The initial handshake would look something like:=C2=A0 > > > > > =C2=A0* Alice -> Bob: alice_encaps || initiator_garbage > > > > > =C2=A0 =C2=A0=C2=A0* Alice derives an encapsulation key, and send= s it to Bob. > > > > >=20 > > > > > =C2=A0* Bob -> Alice: ml_kem_capsule || responder_garbage || resp= onder_garbage_terminator || first_encrypted_packet > > > > > =C2=A0 =C2=A0* Bob uses Alice's encapsulation key to encapsulate = a random secret, and > > > > > =C2=A0 =C2=A0 =C2=A0sends it over to Alice. He can also encrypt t= he first message at this > > > > > =C2=A0 =C2=A0 =C2=A0point. > > > > >=20 > > > > > =C2=A0* Alice -> Bob: initiator_garbage_terminator || first_encry= pted_packet > > > > > =C2=A0 =C2=A0* Alice de-encapsulates the shared secret, and can n= ow also start to encrypt > > > > > =C2=A0 =C2=A0 =C2=A0messages. > > > > >=20 > > > > > We'd then replace `v2_ecdh` with something like a `v3_mlkem` that= derives the > > > > > final shared secret based on the sent/received transcript up unti= l that point: > > > > > =C2=A0=C2=A0* `sha256_tagged("bip324_ml_kem", ml_kem_secret, alic= e_encaps, ml_kem_capsule)` > > > > >=20 > > > > > ### Hybrid ML-KEM P2P Encrypted Handshake > > > > >=20 > > > > > If we want to use a hybrid combiner, then along side the normal e= llswift keys, > > > > > the ML-KEM-768 encap key is also sent: > > > > >=20 > > > > > =C2=A0* Alice -> Bob: ellswift_alice || alice_encaps || initiator= _garbage > > > > > =C2=A0* Bob -> Alice: ellswift_bob || ml_kem_capsule || responder= _garbage || responder_garbage_terminator || first_encrypted_packet > > > > > =C2=A0* Alice -> Bob: initiator_garbage_terminator || first_encry= pted_packet > > > > >=20 > > > > > Then following guidelines of [7], we'd then replace `v2_ecdh` wit= h something > > > > > like `v3_hybrid_shared_secret`: > > > > > =C2=A0=C2=A0* `sha256_tagged("bip324_ellswift_xonly_ecdh_mlkem_76= 8", ml_kem_ss, ecdh_point_x32, alice_encaps, ml_kem_capsule, ellswift_alice= , ellswift_bob)` > > > > >=20 > > > > > ## PQ/Hybrid Obfuscated KEMs > > > > >=20 > > > > > At this point, those that are familiar with BIP 324 will recogniz= e that both > > > > > the pure PQ and hybrid versions renders the ElligatorSwift usage = pretty much > > > > > useless. ElligatorSwift encodes a 32-byte public key as a 64-byte= value which > > > > > is indistinguishable from a uniformly distributed bitstream. In a= bubble, this > > > > > means that the initial BIP 324 handshake to a 3rd party observer = just looks > > > > > like random bytes. However, with the introduction of ML-KEM, the = ML-KEM > > > > > encapsulation key is sent in plaintext over the wire. An ML-KEM k= ey has > > > > > identifiable structure, as it's a giant vector of polynomial coef= ficients mod > > > > > 3329, which is easily recognizable over the wire. > > > > >=20 > > > > > Luckily, there's an ML-KEM analogue to ElligatorSwift, called Kem= eleon > > > > > [8][9][10]! In a similar fashion to ElligatorSwift, it takes an M= L-KEM public > > > > > key, then encodes it as one giant integer, utilizing rejection sa= mpling. > > > > > Kemeleon applies this mapping both to the encapsulation keys, and= also the > > > > > capsule ciphertext that encrypts the shared secrets. The ML-KEM k= eys end up > > > > > being a bit smaller, while the ciphertexts map to a larger value.= Another > > > > > tradeoff is that the Kemeleon key generation is ~3x slower than n= ormal ML-KEM > > > > > generation. > > > > >=20 > > > > > One thing to note here is that Kemeleon's "looks random" property= isn't quite > > > > > on the same footing as ElligatorSwift's. ElligatorSwift is statis= tically > > > > > indistinguishable from random, since every 512-bit string is a va= lid encoding. > > > > > Kemeleon's indistinguishability is computational, resting on a Mo= dule-LWE > > > > > style assumption. So if you naively concatenate an ElligatorSwift= key and a > > > > > Kemeleon key, the pair is only as obfuscated as the weakest visib= le half. This > > > > > asymmetry is what motivates the OEINC construction discussed belo= w. > > > > >=20 > > > > > This brings us to our second design question.... > > > > >=20 > > > > > Do we still want to ensure that the BIP-324 handshake looks ident= ical to a > > > > > pseudorandom bytestream from the very first message? > > > > >=20 > > > > > Assuming yes, then AFAICT, we have two classes of options here:= =C2=A0 > > > > > =C2=A0=C2=A01. Retain the existing BIP-324 outer ElligatorSwift h= andshake, but use ML-KEM > > > > > =C2=A0 =C2=A0 =C2=A0within that initial encrypted transport to up= grade to a PQ shared secret. > > > > >=20 > > > > > =C2=A0=C2=A02. Use the Outer Encrypts Inner Nested Combiner (OEIN= C - "OINK") combiner > > > > > =C2=A0 =C2=A0 =C2=A0from [8]. > > > > >=20 > > > > > =C2=A0=C2=A03. Attempt to adapt Drivel from [8] into the Bitcoin = p2p setting. > > > > >=20 > > > > > ### Classical Encrypted Channel Upgrades to PQ > > > > >=20 > > > > > With the first option, we simply use one KEM right after the othe= r. So BIP 324 > > > > > v2 would be mostly unchanged, then we _upgrade_ to BIP 324 v3 wit= hin v2.=C2=A0 > > > > >=20 > > > > > A sketch of this would be something like: > > > > > =C2=A0=C2=A0* Phase 0: normal BIP 324 handshake > > > > > =C2=A0=C2=A0* Phase 1: negotiation of PQ KEM scheme over the encr= ypted handshake > > > > > =C2=A0 =C2=A0 =C2=A0* Can be optional, if we just pick a set PQ K= EM scheme. > > > > > =C2=A0 =C2=A0 =C2=A0* Before this point, no Bitcoin p2p message s= hould be sent, as the channel > > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0isn't PQC protected yet. > > > > > =C2=A0=C2=A0* Phase 2: do normal ML-KEM within the ElligatorSwift= derived encrypted > > > > > =C2=A0 =C2=A0=C2=A0transport > > > > > =C2=A0 =C2=A0 =C2=A01. Alice sends the encapsulation key > > > > > =C2=A0 =C2=A0 =C2=A02. Bob derives a secrets, encrypts it using t= he encapsulation key > > > > > =C2=A0 =C2=A0 =C2=A03. Both sides then derive a PQ shared secret,= ss_PQ > > > > > =C2=A0=C2=A0* Phase 3: both sides use a hybrid combiner like sket= ched out above to derive > > > > > =C2=A0 =C2=A0=C2=A0a new set of transport keys > > > > > =C2=A0=C2=A0* Phase 4: both sides rekey, switching over to a new = the transport keys > > > > >=20 > > > > > The upside of this option is that the outer part of BIP 324 remai= ns unchanged, > > > > > then with another round trip, we're able to upgrade the encryptio= n keys to PQ > > > > > hybrid security. The downside is that the very first messages sen= t aren't PQ > > > > > from the start, but a PQ adversary wouldn't be able to decrypt th= e actual > > > > > Bitcoin p2p messages (as we wait to send those until the upgrade)= . The > > > > > handshake still looks like just random bytes. > > > > >=20 > > > > > ### Outer Encrypts Inner Nested Combiner > > > > >=20 > > > > > For the second option, [8] (with talk video [9] and slides [10]) = describes an > > > > > OEINC scheme where the outer KEM > > > > > encrypts the inner KEM, wherein the KEM ciphertext of an inner KE= M is encrypted > > > > > using a shared secret derived from the outer KEM. The two KEM cip= hertexts and > > > > > the two derived keys are then used alongside a hybrid combiner to= derive a > > > > > final shared secret.=C2=A0 > > > > >=20 > > > > > Unlike the classical-then-pq-upgrade that establishes a classical= channel, then > > > > > uses that to upgrade to pq channel, OEINC is a special hybrid com= biner that > > > > > achieves a similar output but in one swoop. It defines a special = KEM, which can > > > > > then be used as the KEM in the very first handshake I sketched ou= t. > > > > >=20 > > > > > A sketch of this KEM looks something like: > > > > > =C2=A0=C2=A0* Setup: > > > > > =C2=A0 =C2=A0=C2=A0* The outer KEM is BIP 324's ElligatorSwift-en= coded secp256k1 DHKEM. > > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0* It serves as the outer KEM because i= ts on-wire encoding is > > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statistically indistinguishable= from random. > > > > > =C2=A0 =C2=A0=C2=A0* The inner KEM is ML-Kemeleon. > > > > >=20 > > > > > =C2=A0=C2=A0* KeyGen(): > > > > > =C2=A0 =C2=A0=C2=A0* (kem_secret_outer, kem_pubkey_outer) =3D out= KEM.Gen() > > > > > =C2=A0 =C2=A0=C2=A0* (kem_secret_inner, kem_pubkey_inner) =3D inK= EM.Gen() > > > > > =C2=A0 =C2=A0=C2=A0* combined_pubkey =3D (kem_pubkey_outer, kem_p= ubkey_inner) > > > > > =C2=A0 =C2=A0=C2=A0* combined_secret =3D (kem_secret_outer, kem_s= ecret_inner) > > > > >=20 > > > > > =C2=A0=C2=A0* Encaps(combined_pubkey): > > > > > =C2=A0 =C2=A0=C2=A0* (shared_secret_outer, capsule_outer) =3D out= KEM.Encap(kem_pubkey_outer) > > > > > =C2=A0 =C2=A0=C2=A0* (encrypt_key_1, encrypt_key_2) =3D KDF(share= d_secret_outer) > > > > > =C2=A0 =C2=A0=C2=A0* (shared_secret_inner, capsule_inner) =3D inK= EM.Encap(kem_pubkey_inner) > > > > > =C2=A0 =C2=A0=C2=A0* encrypted_capsule_inner =3D encrypt(encrypt_= key_1, capsule_inner) > > > > > =C2=A0 =C2=A0=C2=A0* combined_capsule =3D capsule_outer || encryp= ted_capsule_inner > > > > > =C2=A0 =C2=A0=C2=A0* combined_shared_secret =3D combine(encrypt_k= ey_2, shared_secret_inner, combined_capsule) > > > > >=20 > > > > > =C2=A0=C2=A0* Decaps(combined_secret, combined_capsule): > > > > > =C2=A0 =C2=A0=C2=A0* (capsule_outer, encrypted_capsule_inner) =3D= combined_capsule > > > > > =C2=A0 =C2=A0=C2=A0* shared_secret_outer =3D outKEM.Decaps(kem_se= cret_outer, capsule_outer) > > > > > =C2=A0 =C2=A0=C2=A0* (encrypt_key_1, encrypt_key_2) =3D KDF(share= d_secret_outer) > > > > > =C2=A0 =C2=A0=C2=A0* capsule_inner =3D decrypt(encrypt_key_1, enc= rypted_capsule_inner) > > > > > =C2=A0 =C2=A0=C2=A0* shared_secret_inner =3D inKEM.Decaps(kem_sec= ret_inner, capsule_inner) > > > > > =C2=A0 =C2=A0=C2=A0* combined_shared_secret =3D combine(encrypt_k= ey_2, shared_secret_inner, combined_capsule) > > > > >=20 > > > > >=20 > > > > > This is done over just sending the two encapsulated secrets plain= ly as I > > > > > outlined above in order to achieve a stronger security notion. Th= e issue with > > > > > this though is that though ciphertext uniformity (the encapsulate= d secrets) is > > > > > achieved, the two public keys sent are randomly looking, but not = in a uniform > > > > > manner. In practice, this might not really matter much AFAICT (a = theoretical > > > > > adversary would be able to distinguish the Elligator half from th= e Kemeleon > > > > > half). > > > > >=20 > > > > > ### Drivel: PQ-Obfuscated Authentication > > > > >=20 > > > > > The biggest issue with Drivel as a fit for BIP 324 is that it exp= ects the > > > > > initiator to already know a long term static public key for the r= esponder. In > > > > > the case of BIP 324, only ephemeral keys are exchanged, so there'= s no long > > > > > term public keys known to either side. > > > > >=20 > > > > > To get around this, we could extend BIP 155 (or make a new one li= kely, given > > > > > size limits) to include a signed OKEM key. However then that woul= d introduce > > > > > authentication into the combined set, which explicitly wasn't a d= esign goal > > > > > of BIP 324. > > > > >=20 > > > > > With that caveat in mind, here's the construction itself. Drivel = [8] combines > > > > > the OEINC scheme with another layer that out-of-the-box assumes a= n asymmetric > > > > > protocol within a set client and server. The client uses an exist= ing OEINC > > > > > KEM public key published by the server to then encrypt a fresh ne= w ephemeral > > > > > KEM. > > > > >=20 > > > > > -----=C2=A0 > > > > >=20 > > > > > So there we have it. Before drafting a concrete v3 transport, we = need to > > > > > decide if we want a hybrid KEM, or are fine with a pure PQ KEM. T= hen we need to > > > > > decide if we want to attempt to maintain the current quality wher= e the p2p > > > > > handshake transcript is indistinguishable from random. If yes, th= en that forces > > > > > another series of decisions re how to construct/compose an oblivi= ous KEM from > > > > > available primitives. > > > > >=20 > > > > > At a glance, the route of classical-then-pq-upgrade seems to be t= he simplest. > > > > > BIP 324 stays as is, then we run ML-KEM within that. The ML-KEM k= eys are > > > > > encrypted, so there's no need to sprinkle in the layer of Kemeleo= n. > > > > >=20 > > > > > If we want a nice combined protocol, then we should investigate t= he OEINC > > > > > route. It's more data to send as part of the initial handshake, b= ut we still > > > > > keep ElligatorSwift and use that as the outer KEM. > > > > >=20 > > > > > If for some reason we're concerned with a future adversary gainin= g a > > > > > distinguisher for Kemeleon, then maybe we need to bite the bullet= and also > > > > > roll out a full blown PQ authentication protocol along side every= thing. > > > > >=20 > > > > > One thing worth flagging for any of the byte-0 designs (where PQ = material is > > > > > sent in the clear on the very first flight, like the hybrid and O= EINC sketches > > > > > above): ML-KEM-768 makes the responder do real work before it can= decide if a > > > > > connection is even legit. Today, the responder only needs the fir= st 64 bytes > > > > > of an ElligatorSwift share before it can derive the shared secret= . With > > > > > ML-KEM-768, the responder has to read and validate a 1184 byte en= capsulation > > > > > key before running Encaps, and FIPS 203 mandates input checks on = every Encaps > > > > > and Decaps. In a permissionless P2P network, that's a meaningful = change in > > > > > inbound DoS surface, and probably calls for stricter handshake by= te limits, > > > > > tighter timeouts, and possibly some form of stateless cookie/puzz= le if > > > > > handshake floods become a real problem. The classical-then-pq-upg= rade path > > > > > sidesteps most of this since the PQ material only shows up after = the v2 > > > > > channel is up. > > > > >=20 > > > > > With all that said, after the above design decisions are addresse= d, there > > > > > aren't too many concrete blockers here w.r.t rolling this out. Of= course the > > > > > development (eg: selecting/creating a library for ML-KEM and mayb= e > > > > > ML-Kemeleon), and upgrade will take some time. But unlike the con= sensus > > > > > layer, p2p encryption doesn't require the widespread market agree= ment that an > > > > > actual soft fork does. BIP 324 is a much shorter walk to PQ than = the consensus > > > > > layer, and serves as a sort of PQ warm up before the bigger soft = fork is > > > > > tackled.=C2=A0 > > > > >=20 > > > > >=20 > > > > > -- Laolu > > > > >=20 > > > > > [1]:=C2=A0https://en.wikipedia.org/wiki/ML-KEM > > > > > [2]:=C2=A0https://csrc.nist.gov/pubs/fips/203/final > > > > > [3]:=C2=A0https://en.wikipedia.org/wiki/Learning_with_errors > > > > > [4]: This statement ignores Isogeny based crypto, and also SWOOSH= [5] as it requires 200 KB pubkeys > > > > > [5]:=C2=A0https://eprint.iacr.org/2023/271 > > > > > [6]:=C2=A0https://eprint.iacr.org/2018/024 > > > > > [7]:=C2=A0https://eprint.iacr.org/2020/1364 > > > > > [8]:=C2=A0https://eprint.iacr.org/2024/1086 > > > > > [9]:=C2=A0https://www.youtube.com/watch?v=3DCvFCYUq5rGg > > > > > [10]:=C2=A0https://csrc.nist.gov/csrc/media/Presentations/2025/ke= meleon/images-media/kemeleon.pdf > > > > > [11]:=C2=A0https://en.wikipedia.org/wiki/Harvest_now,_decrypt_lat= er > > > > >=20 > > > > > --=C2=A0 > > > > > You received this message because you are subscribed to the Googl= e Groups "Bitcoin Development Mailing List" group. > > > > > To unsubscribe from this group and stop receiving emails from it,= send an email to=C2=A0bitcoindev+unsubscribe@googlegroups.com. > > > > > To view this discussion visit=C2=A0https://groups.google.com/d/ms= gid/bitcoindev/CAO3Pvs9U3prZJiDs0Ns7LSA07R8hM-GQou_FcTZZz-JUQpUYHw%40mail.g= mail.com. > > >=20 > > >=20 > > > --=C2=A0 > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to=C2=A0bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit=C2=A0https://groups.google.com/d/msgid/= bitcoindev/CAO3Pvs8i%3DpLP30nRh_iyjSRJXne19wNezmQmo%3DJAk8%2BE4uJPhg%40mail= .gmail.com. > >=20 > >=20 > >=20 > > -- > > You received this message because you are subscribed to the Google Grou= ps "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/bitcoin= dev/547ADFCA-2BB1-4E16-A26A-C92262EBBD84%40gmail.com. --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= ZPM_caMVKdoxGyFFqALpkG-QUTPTSqx_xMTZZqUB3b8-zGkChYw2EGcPTsp5SdxrK2rx0mmCMYa= SenjoNz2q6I52drWn8LeuooADmcO3AEE%3D%40proton.me. -----------------------640d12b7438260bda61005e47ede9a9e Content-Type: multipart/related;boundary=---------------------c70a5c3928e5b3ecf32bcda583ab5636 -----------------------c70a5c3928e5b3ecf32bcda583ab5636 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oopsie, I j= ust saw Laolu's footnote #4 about ignoring isogeny crypto. Guess I should l= earn to read better :P

regards,
conduition
On Friday, May 8th, 2026 at 8:21 PM, conduition <conduition@prot= on.me> wrote:
Hi all,


One thing worth noting is that = AFAICT, so far in the NIST PQC world [4], there is no known non= -interactive key exchange protocol like we enjoy today with ECDH. IIUC, the= reason is that lattice based schemes derived from the LWE [3] problem, who= se security is predicated on using "noise" to hide a secret value. For thes= e cryptosystems, usually a type of "hint" is sent to make everything work o= ut nicely like in ECDH. However, in the stricter non-interactive setting&nb= sp;(no messages sent), this doesn't map cleanly. 

It's important to emphasize this only considers the N= IST-standardized KEMs. If we zoom out to the broader ecosystem of PQ PKE ca= ndidates, there are several options for non-interactive key exchange system= s that'd be a drop-in replacement for ECDH.

For instance= , oriented isogeny-based systems like CSIDH [1] [2] permit this kind of con= struction. Both parties publish a short (64 to 128 byte) pubkey and can per= form key exchange as soon as they've seen the peer's pubkey, no additional = messages required. The down side of CSIDH is that it's quite slow, so it is= most useful when pubkeys are static or otherwise don't change much. There = has been a lot of work done with new faster schemes [3] or speeding up CSIDH with better implementations [4] but still key exc= hange can take a good few dozen milliseconds. 

In genera= l, any post-quantum-secure commutative group action scheme allows non-inter= active key exchange. CSIDH is just one such example, and I'm sure there are= and will be others.

Being unversed in BIP324 as yet, I'm not sure how crucial thi= s non-interactivity property is to the protocol. If it's not a big deal, th= en I'd gladly toss my hat in for lattices and a hybridized ML-KEM construct= ion, given so much of the internet is already migrating to this. It makes s= ense to follow standards if we can. Going full-TLS would probably be overki= ll IMO - It is designed for a very different (centralized) PKI architecture= and would buy us a ticket for a train we probably don't want to ride.

=
Maybe there= 's a more applicable standard, a la Noise/Wireguard? For a possible impleme= ntation reference, see [5]. Otherwise rolling our own standard seems like t= he way to go, especially if we can do so in a way that is reusable for othe= r use-cases beyond Bitcoin.

Also, if we go with a hybrid scheme, we should have cl= ear migration paths to transition to either pure PQC (if a CRQC appears and= breaks ECDH, we might as well discard it), or back to classical ECDH (if C= RQCs turn out to be impossible).

regards,
conduition

[2]: https://eprint.iacr.org/2018/383



On Thursday, May 7th, 2026 at 1:45 AM, Jonas Schnelli <jonas.sch= nelli@gmail.com> wrote:
Thanks for writing this up Laolu.

I think option 1 (classical-then-PQ-upgrade) is probably the right path, m= ostly because it keeps the byte-0 pseudorandomness property without needing= Kemeleon or any new obfuscation primitive.

If the= ML-KEM exchange happens inside the already-established v2 ChaCha20Poly1305= channel, then to a present-day classical observer the bytes should still l= ook random,... the inner PQ handshake is just more ciphertext. A future QC = adversary doing harvest-now-decrypt-later would break the outer ECDH eventu= ally, but I think they'd then still have to break ML-KEM-768 to get the v3 = transport keys, which is kind of the whole point. So we'd probably get hybr= id security against the QC threat and also keep the property that today's w= ire bytes are indistinguishable from random.

That = said, I'm not sure how far we should really take the pseudorandomness argum= ent,... traffic shape (packet sizes, timings, query/response patterns) prob= ably already reveals quite a bit about what's going on, so the byte-content= randomness is only one part of the picture.

The e= xtra round trip is probably fine given how long Bitcoin P2P connections liv= e. The DoS angle you flagged might also be smaller in option 1, since the r= esponder still commits after 64 bytes and not after a 1184-byte ML-KEM key,= ... though I haven't thought hard about wether there are other DoS vectors = the inner upgrade introduces.

On Ethan's TLS 1.3 s= uggestionm,... I don't think it really fits. Apart from the dependency cost= (which we deliberately kept low in BIP 324), TLS has it's own fingerprint,= which would probably undo the censorship-resistance angle. And it bundles = authentication with encryption, which we explicitly decoupled.
One thing worth looking at: OpenSSH (whose chacha20-poly1305 c= onstruction we drew from originally) shipped mlkem768x25519-sha256 as defau= lt in 10.0 last year, and they just concatenate-and-hash the two shared sec= rets. Their threat model doesn't care about pseudorandomness so they can se= nd ML-KEM material in the clear, but the combiner shape is probably a reaso= nable reference for ours.

/jonas

On May 6, 2026, at 12:15=E2=80=AFPM, Olaoluwa O= suntokun <laolu32@gmail.com> wrote:

Hi Ethan, 

That's a great questio= n. 

First, I don't= speak for Bitcoin Core by any means (btcd has also implemented
BIP 324 = FWIW). Based on past observed behavior, they typically prefer to keep
de= pendencies slim. Many years ago there was a concerted push to remove openss= l
as a dependency from the project. So I would imagine the idea of rolli= ng out
full blown TLS 1.3 might encounter some resistance.

In ter= ms of cryptography, BIP 324 as defined uses secp256k1. TLS 1.3 as
specif= ied doesn't support secp256k1 within the set of supported cipher suites.
If ensuring that BIP 324 continues to implement an oblivious KEM is a = key
requirement, then TLS 1.3 doesn't fit the bill.

Regarding a h= ybrid PQ KEM, there exists an IETF to add a new key agreement
suite to T= LS 1.3: https= ://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/.
Only secp25= 6+384(r1) and x25519 are supported as elliptic curves in this draft.
One additional aspect is that today BIP 324 doesn't implement authenticati= on at
all, you only get confidentiality. TLS 1.3 would mean introducing = certificates
in some fashion, thereby coupling concerns from the origina= l PoV of Bip 324.

BIP 324 also includes as section in the BIP detail= ing the rationale of BIP 324
over a more general purpose protocol (menti= ons some of the points above):
https://githu= b.com/bitcoin/bips/blob/master/bip-0324.mediawiki#:~:text=3DWhy%20not%20use= %20a%20general%2Dpurpose%20transport%20encryption%20protocol%3F.

-- Laolu



On Tue, May 5, 2026 at 2:18=E2=80=AFPM Ethan Heilman &l= t;= eth3rs@gmail.com> wrote:
Thanks Laolu for thinking through making PQ B= IP 324 and writing this up.

Reading through what you wrote made me w= hat wonder, why not use this as an opportunity to move to TLS 1.3?

W= hat's the case against using TLS 1.3 for PQ P2P connection encryption? Is t= here some functionality that TLS 1.3 is lacking that we really want?  = Is the case against solely to not have TLS 1.3 as a complex dependency in b= itcoin-core?

The advantages of= TLS 1.3:

1. Make Bitcoi= n P2P connections blend in with all the other TLS connections. This isn't s= trong privacy, you can distinguish TLS encrypted Bitcoin traffic via timing= and size, but it reduces accidents where a firewall sees an unknown protoc= ol and blocks it.

2. Use= of QUIC for faster relay, oblivious HTTP and QUIC tunnels-in-tunnels for p= rivate relay and similar protocols.

3. Lots of eyeballs o= n TLS 1.3, we don't need to build or maintain it.


On Tue,= May 5, 2026, 00:41 Olaoluwa Osuntokun <laolu32@gmail.c= om> wrote:
Hi= y'all, 

In case y= ou weren't already tired of all the recent dev list chatter re post
quan= tum cryptography, here's another!

When the topic of Bitcoin transiti= oning to a post quantum world is brought up,
the discussion typically fo= cuses on the consensus layer re swapping out
vulnerable signature scheme= s. However, the consensus layer isn't the only area
of Bitcoin that reli= es in cryptography that would be broken in the face of a
powerful quantu= m computer! That's right, I'm talking about BIP 324, the peer to
peer en= cryption BIP for Bitcoin.

Like everything else on the Internet today= , BIP 324 uses ECDH to allow two
connecting peers to derive a shared sec= ret known only to them, which is then
used to encrypt all traffic betwee= n them. As ECDH relies on Elliptic Curve
cryptography, a future quantum = computer would be able to eavesdrop on a p2p
handshake transcript, then = derive the underlying private keys to the ephemeral
ECDH public key, per= mitting it to decrypt all traffic. It's actually worse than
that, as tod= ay adversaries can collect all encrypted p2p Bitcoin traffic, with
the h= ope of being able to decrypt it all at a future date. This is commonly
r= eferred to as the: "harvest, decrypt later" (HNDL) strategy [11].

Co= mpared to a consensus change, which requires widespread market agreement, a= nd
coordination to achieve, upgrading BIP 324 to be post quantum resista= nt is a
much lower hanging fruit worthy of pursing immediately.

L= ast week I starting thinking a bit about this topic, brushing up on the lat= est
literature/techniques, and stumbled onto a few key design questions.= The goal
of this post isn't to propose a new concrete p2p encryption BI= P, instead I want
to start discussion on the various design tradeoffs th= at came up as I was
researching this p2p encryption transition.

#= # PQ BIP 324 Design Questions

1. Do we want to pursue a hybrid KEM (= key encapsulation mechanism), or go with
   a pure PQ KEM?
=
2. Is it still a key requirement that the initial handshake be
 = ;  indistinguishable from a random byte string?

   2a= . If yes to the above, then should we go with classical-then-pq-upgrade,   or a one shot hybrid oblivious KEM.


## A Brief Int= ro to KEMs + ML-KEM

First, let's introduce the new primitive we have= to work with: ML-KEM
(Module-Lattice-Based Key-Encapsulation Mechanism)= [1][2]. As it says on the
tin, ML-KEM is a lattice based Key-Encapsulat= ion Mechanism. The phrase KEM
might sound unfamiliar with those comforta= ble with ECDH, but ECDH is actually a
KEM itself.

A KEM has 3 alg= orithms:
  * KeyG= en() -> {sk, pk}
     * Generates a public/private sec= ret key pair

  * Encaps(pub) -> {secret, capsule}
     * Generates = a new secret value, and a "capsule", which only the holder of
  &nb= sp;    pub can use to obtain the secret value.

  * Decaps(priv, capsule) ->= secret
     * Uses the private key to extract the secret= from the capsule


If you squint a bit, then you'll see that ECDH= is a KEM, and a rather elegant
one at that:
  * KeyGen() -> {k, k*G}
   =   * Normal EC key g= eneration. 

 =  * Encaps(pub) -> {cap= sule =3D x*G, secret =3D pub*x}
      * The core ECDH routine. The ephemeral publi= c key is actually the
        "capsule". The resulting secret is the ECDH out= put with the remote
        party's KEM public key and the local secret.
<= br>  * Decaps(priv, = capsule) -> secret =3D priv * capsule
      * The receiver completes the key ex= change using the ephemeral public key
        and their own private key.
<= br>ECIES is another flavor of EC based KEM.

One thing worth noting i= s that AFAICT, so far in the NIST PQC world [4], there is
no known non-i= nteractive key exchange protocol like we enjoy today with ECDH.
IIUC, th= e reason is that lattice based schemes derived from the LWE [3]
problem,= whose security is predicated on using "noise" to hide a secret value.
F= or these cryptosystems, usually a type of "hint" is sent to make everything=
work out nicely like in ECDH. However, in the stricter non-interactive = setting
(no messages sent), this doesn't map cleanly.

As a result= , ML-KEM looks more like a hybrid encryption protocol (Alice
encrypts a = shared secret to bob using asymmetric lattice crypto).

## To Hybrid = KEM, Or Not to Hybrid KEM

This brings us to our first design questio= n....

Should we use a hybrid KEM or a pure post quantum one? 

A hybrid KEM would keep = the existing ECDH, _also_ do ML-KEM, then securely
combine (there's some= subtlety there, see [6][7]) the resulting in a
final secret value for e= ncryption. A hybrid KEM is attractive as an encryption
channel derived f= rom such a KEM is secure if _any_ of the combined schemes are
secure. Th= is permits schemes to hedge a bit, as hey, maybe the PQ stuff is
actuall= y broken in the future but ECDH isn't. If it's the other way around,
the= n your encryption scheme is still secure.

### Pure ML-KEM P2P Encryp= ted Handshake

If we opt to not use a hybrid scheme, then the Elligat= or layer can be dropped
all together. Instead, the 1.1 KB (ML-KEM-768) e= ncapsulation keys are sent,
keeping the trailing garbage+terminator in t= act. 

The initial = handshake would look something like:&= nbsp;
 * Alice -> Bob: alice_encaps || initiator_garbage<= br>    * Alice = derives an encapsulation key, and sends it to Bob.

 * Bob ->= Alice: ml_kem_capsule || responder_garbage || responder_garbage_terminator= || first_encrypted_packet
   * Bob uses Alice's encapsulation= key to encapsulate a random secret, and
     sends it ov= er to Alice. He can also encrypt the first message at this
   =  point.

 * Alice -> Bob: initiator_garbage_terminator = || first_encrypted_packet
   * Alice de-encapsulates the share= d secret, and can now also start to encrypt
     messages= .

We'd then replace `v2_ecdh` with something like a `v3_mlkem` that = derives the
final shared secret based on the sent/received transcript up= until that point:
  * `sha256_tagged("bip324_ml_kem", ml_kem_secret, alice_encaps, ml_kem_c= apsule)`

### Hybrid ML-KEM P2P Encrypted Handshake

If we want= to use a hybrid combiner, then along side the normal ellswift keys,
the= ML-KEM-768 encap key is also sent:

 * Alice -> Bob: ellswif= t_alice || alice_encaps || initiator_garbage
 * Bob -> Alice: el= lswift_bob || ml_kem_capsule || responder_garbage || responder_garbage_term= inator || first_encrypted_packet
 * Alice -> Bob: initiator_garb= age_terminator || first_encrypted_packet

Then following guidelines o= f [7], we'd then replace `v2_ecdh` with something
like `v3_hybrid_shared= _secret`:
  * `sh= a256_tagged("bip324_ellswift_xonly_ecdh_mlkem_768", ml_kem_ss, ecdh_point_x= 32, alice_encaps, ml_kem_capsule, ellswift_alice, ellswift_bob)`

## = PQ/Hybrid Obfuscated KEMs

At this point, those that are familiar wit= h BIP 324 will recognize that both
the pure PQ and hybrid versions rende= rs the ElligatorSwift usage pretty much
useless. ElligatorSwift encodes = a 32-byte public key as a 64-byte value which
is indistinguishable from = a uniformly distributed bitstream. In a bubble, this
means that the init= ial BIP 324 handshake to a 3rd party observer just looks
like random byt= es. However, with the introduction of ML-KEM, the ML-KEM
encapsulation k= ey is sent in plaintext over the wire. An ML-KEM key has
identifiable st= ructure, as it's a giant vector of polynomial coefficients mod
3329, whi= ch is easily recognizable over the wire.

Luckily, there's an ML-KEM = analogue to ElligatorSwift, called Kemeleon
[8][9][10]! In a similar fas= hion to ElligatorSwift, it takes an ML-KEM public
key, then encodes it a= s one giant integer, utilizing rejection sampling.
Kemeleon applies this= mapping both to the encapsulation keys, and also the
capsule ciphertext= that encrypts the shared secrets. The ML-KEM keys end up
being a bit sm= aller, while the ciphertexts map to a larger value. Another
tradeoff is = that the Kemeleon key generation is ~3x slower than normal ML-KEM
genera= tion.

One thing to note here is that Kemeleon's "looks random" prope= rty isn't quite
on the same footing as ElligatorSwift's. ElligatorSwift = is statistically
indistinguishable from random, since every 512-bit stri= ng is a valid encoding.
Kemeleon's indistinguishability is computational= , resting on a Module-LWE
style assumption. So if you naively concatenat= e an ElligatorSwift key and a
Kemeleon key, the pair is only as obfuscat= ed as the weakest visible half. This
asymmetry is what motivates the OEI= NC construction discussed below.

This brings us to our second design= question....

Do we still want to ensure that the BIP-324 handshake = looks identical to a
pseudorandom bytestream from the very first message= ?

Assuming yes, then AFAICT, we have two classes of options here: 
  1. Retain the existing BIP-324 outer Elli= gatorSwift handshake, but use ML-KEM
     within that ini= tial encrypted transport to upgrade to a PQ shared secret.

  2. Use the Outer Encrypts I= nner Nested Combiner (OEINC - "OINK") combiner
     from = [8].

  3. Att= empt to adapt Drivel from [8] into the Bitcoin p2p setting.

### Clas= sical Encrypted Channel Upgrades to PQ

With the first option, we sim= ply use one KEM right after the other. So BIP 324
v2 would be mostly unc= hanged, then we _upgrade_ to BIP 324 v3 within v2. 

A sketch of this would be something like:=
  * Phase 0: nor= mal BIP 324 handshake
  = * Phase 1: negotiation of PQ KEM scheme over the encrypted handshake=
     * Can be optional, if we just pick a set PQ KEM sch= eme.
     * Before this point, no Bitcoin p2p message sho= uld be sent, as the channel
       isn't PQC protect= ed yet.
  * Phase= 2: do normal ML-KEM within the ElligatorSwift derived encrypted
  =   transport
 = ;    1. Alice sends the encapsulation key
     = 2. Bob derives a secrets, encrypts it using the encapsulation key
 =    3. Both sides then derive a PQ shared secret, ss_PQ
 =  * Phase 3: both sides us= e a hybrid combiner like sketched out above to derive
    a new set of transport keys  * Phase 4: both = sides rekey, switching over to a new the transport keys

The upside o= f this option is that the outer part of BIP 324 remains unchanged,
then = with another round trip, we're able to upgrade the encryption keys to PQhybrid security. The downside is that the very first messages sent aren't = PQ
from the start, but a PQ adversary wouldn't be able to decrypt the ac= tual
Bitcoin p2p messages (as we wait to send those until the upgrade). = The
handshake still looks like just random bytes.

### Outer Encry= pts Inner Nested Combiner

For the second option, [8] (with talk vide= o [9] and slides [10]) describes an
OEINC scheme where the outer KEM
= encrypts the inner KEM, wherein the KEM ciphertext of an inner KEM is encry= pted
using a shared secret derived from the outer KEM. The two KEM ciphe= rtexts and
the two derived keys are then used alongside a hybrid combine= r to derive a
final shared secret.=  

Unlike the classical-then-pq-upgrade that establishes = a classical channel, then
uses that to upgrade to pq channel, OEINC is a= special hybrid combiner that
achieves a similar output but in one swoop= . It defines a special KEM, which can
then be used as the KEM in the ver= y first handshake I sketched out.

A sketch of this KEM looks somethi= ng like:
  * Setu= p:
    * The= outer KEM is BIP 324's ElligatorSwift-encoded secp256k1 DHKEM.
  &= nbsp;    * It serves as the outer KEM because its on-wire encodin= g is
         statistically indistinguishable f= rom random.
    * The inner KEM is ML-Kemeleon.

  * KeyGen():
    * (kem_secret_outer, kem_pubkey_outer) =3D out= KEM.Gen()
    * (kem_secret_inner, kem_pubkey_inner) =3D inKEM.Gen()
    * combined_pubkey =3D (kem= _pubkey_outer, kem_pubkey_inner)
    * combined_secret =3D (kem_secret_outer, kem_secre= t_inner)

  * = Encaps(combined_pubkey):
    * (shared_secret_outer, capsule_outer) =3D outKEM.Encap(ke= m_pubkey_outer)
    = ;* (encrypt_key_1, encrypt_key_2) =3D KDF(shared_secret_outer)
&n= bsp;   * (shared_sec= ret_inner, capsule_inner) =3D inKEM.Encap(kem_pubkey_inner)
   = ; * encrypted_capsule_inn= er =3D encrypt(encrypt_key_1, capsule_inner)
    * combined_capsule =3D capsule_outer |= | encrypted_capsule_inner
    * combined_shared_secret =3D combine(encrypt_key_2, share= d_secret_inner, combined_capsule)

  * Decaps(combined_secret, combined_capsule):
&nbs= p;   * (capsule_oute= r, encrypted_capsule_inner) =3D combined_capsule
    * shared_secret_outer =3D outKEM.D= ecaps(kem_secret_outer, capsule_outer)
    * (encrypt_key_1, encrypt_key_2) =3D KDF(sha= red_secret_outer)
   &nb= sp;* capsule_inner =3D decrypt(encrypt_key_1, encrypted_capsule_inne= r)
    * sha= red_secret_inner =3D inKEM.Decaps(kem_secret_inner, capsule_inner)
 = ;   * combined_share= d_secret =3D combine(encrypt_key_2, shared_secret_inner, combined_capsule)<= br>

This is done over just sending the two encapsulated secrets plai= nly as I
outlined above in order to achieve a stronger security notion. = The issue with
this though is that though ciphertext uniformity (the enc= apsulated secrets) is
achieved, the two public keys sent are randomly lo= oking, but not in a uniform
manner. In practice, this might not really m= atter much AFAICT (a theoretical
adversary would be able to distinguish = the Elligator half from the Kemeleon
half).

### Drivel: PQ-Obfusc= ated Authentication

The biggest issue with Drivel as a fit for BIP 3= 24 is that it expects the
initiator to already know a long term static p= ublic key for the responder. In
the case of BIP 324, only ephemeral keys= are exchanged, so there's no long
term public keys known to either side= .

To get around this, we could extend BIP 155 (or make a new one lik= ely, given
size limits) to include a signed OKEM key. However then that = would introduce
authentication into the combined set, which explicitly w= asn't a design goal
of BIP 324.

With that caveat in mind, here's = the construction itself. Drivel [8] combines
the OEINC scheme with anoth= er layer that out-of-the-box assumes an asymmetric
protocol within a set= client and server. The client uses an existing OEINC
KEM public key pub= lished by the server to then encrypt a fresh new ephemeral
KEM.

-= ---- 

So there we = have it. Before drafting a concrete v3 transport, we need to
decide if w= e want a hybrid KEM, or are fine with a pure PQ KEM. Then we need to
dec= ide if we want to attempt to maintain the current quality where the p2p
= handshake transcript is indistinguishable from random. If yes, then that fo= rces
another series of decisions re how to construct/compose an obliviou= s KEM from
available primitives.

At a glance, the route of classi= cal-then-pq-upgrade seems to be the simplest.
BIP 324 stays as is, then = we run ML-KEM within that. The ML-KEM keys are
encrypted, so there's no = need to sprinkle in the layer of Kemeleon.

If we want a nice combine= d protocol, then we should investigate the OEINC
route. It's more data t= o send as part of the initial handshake, but we still
keep ElligatorSwif= t and use that as the outer KEM.

If for some reason we're concerned = with a future adversary gaining a
distinguisher for Kemeleon, then maybe= we need to bite the bullet and also
roll out a full blown PQ authentica= tion protocol along side everything.

One thing worth flagging for an= y of the byte-0 designs (where PQ material is
sent in the clear on the v= ery first flight, like the hybrid and OEINC sketches
above): ML-KEM-768 = makes the responder do real work before it can decide if a
connection is= even legit. Today, the responder only needs the first 64 bytes
of an El= ligatorSwift share before it can derive the shared secret. With
ML-KEM-7= 68, the responder has to read and validate a 1184 byte encapsulation
key= before running Encaps, and FIPS 203 mandates input checks on every Encaps<= br>and Decaps. In a permissionless P2P network, that's a meaningful change = in
inbound DoS surface, and probably calls for stricter handshake byte l= imits,
tighter timeouts, and possibly some form of stateless cookie/puzz= le if
handshake floods become a real problem. The classical-then-pq-upgr= ade path
sidesteps most of this since the PQ material only shows up afte= r the v2
channel is up.

With all that said, after the above desig= n decisions are addressed, there
aren't too many concrete blockers here = w.r.t rolling this out. Of course the
development (eg: selecting/creatin= g a library for ML-KEM and maybe
ML-Kemeleon), and upgrade will take som= e time. But unlike the consensus
layer, p2p encryption doesn't require t= he widespread market agreement that an
actual soft fork does. BIP 324 is= a much shorter walk to PQ than the consensus
layer, and serves as a sor= t of PQ warm up before the bigger soft fork is
tackled. 

-- Laolu

[1]: https://en.wiki= pedia.org/wiki/ML-KEM
[2]:&nbs= p; https://en.wikipedia.org/wiki/Learning_wit= h_errors
[4]: This statement ignores Isogeny based crypto, and also = SWOOSH [5] as it requires 200 KB pubkeys
[5]: https://eprint.iacr.org/2023/271
[6]: https://eprint.iacr.org/2018/024
[7]: https://eprint.iacr.org/2020/1364
[8]: https://eprint.iacr.org/2024/1086
[9]: https://www.youtube.com/watch?v= =3DCvFCYUq5rGg
[10]: https://csrc.nist.gov/csrc/media/P= resentations/2025/kemeleon/images-media/kemeleon.pdf
[11]: https://en.wikipedia.org/w= iki/Harvest_now,_decrypt_later

-- 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.
T= o view this discussion visit https:= //groups.google.com/d/msgid/bitcoindev/CAO3Pvs9U3prZJiDs0Ns7LSA07R8hM-GQou_= FcTZZz-JUQpUYHw%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google= Groups "Bitcoin Development Mailing List" group.
T= o unsubscribe from this group and stop receiving emails from it, send an em= ail to bitcoindev+unsubscribe@googlegroups.com.
<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:= 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; let= ter-spacing: normal; text-align: start; text-indent: 0px; text-transform: n= one; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px= ; text-decoration: none; float: none; display: inline !important;">To view = this discussion visit https://groups.google.com/d/msgid/bitco= indev/CAO3Pvs8i%3DpLP30nRh_iyjSRJXne19wNezmQmo%3DJAk8%2BE4uJPhg%40mail.gmai= l.com To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit = https://groups.google.com/d/msgid/bitcoindev/547ADFCA-2BB1-4E16-A26A-C92262= EBBD84%40gmail.com.


--
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/bitcoindev/ZPM_ca= MVKdoxGyFFqALpkG-QUTPTSqx_xMTZZqUB3b8-zGkChYw2EGcPTsp5SdxrK2rx0mmCMYaSenjoN= z2q6I52drWn8LeuooADmcO3AEE%3D%40proton.me.
-----------------------c70a5c3928e5b3ecf32bcda583ab5636-- -----------------------640d12b7438260bda61005e47ede9a9e-- -----------------------7b74a2ef071299329c0e86f53f07dbbb Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------7b74a2ef071299329c0e86f53f07dbbb-- --------dd4b72cee60ba2b95036e3b59552e6c820d50f86d08c00b14ad28cf27e10226c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmn+qJcJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcme8drb5M75Ss6St9cg7KFONC54qNmZ02yvgviYt P9HX5xYhBEdIka0CMtrLdg13a3gpbO2E9rPFAACPiAD+M8FQ5D8/tIcoImFy +Y1S8YL+tOXm2c6HFvoC0/OgaZ4BAPJIY9GxWO5wOI5rLQE5fooUq3SDjMGd qN4bxTHFG5YI =GSzJ -----END PGP SIGNATURE----- --------dd4b72cee60ba2b95036e3b59552e6c820d50f86d08c00b14ad28cf27e10226c--