From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 27 Aug 2026 08:38:55 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wzcBn-0002Tj-9u for bitcoindev@gnusha.org; Thu, 27 Aug 2026 08:38:55 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-4566537e644sf166683fac.0 for ; Thu, 27 Aug 2026 08:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787845125; x=1788449925; 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:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=1WXl068ZsgIFdYaSSF8f3+HYpMoZ6RZcYLtQvJ+96fk=; b=SOibxZ03tFb9cEY5/4dqxBMOVjw5RaQzsqg9x+al1u2YWsyfYVAVAGAj5DTHb3t3r4 OJsyElCjKAKP3kVE7yYt1qqqzNoxVrJZaqtsYhkPHUCkevRFL69ymZ2u/EpaZ/Wzpqex nxsEB/bz+hmBnF4oWre61s6YxwOVY/IHfZvM897LDevYxk2AzPOCUlo7NgaHgQx81o7w LO59gVdx4VCHvO7byvEEUj90QbhEzUzAkn8dS3UfiL8eb0k6Ae4p/AT+5Yarqz+iYlPx bs6NZmWiMuWrT5bBqK7gP98lx4jx6CmhLQGQNrrV3XAUfxE/Yo78kreOirvxgDUpJfKc y7Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787845125; x=1788449925; 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:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=1WXl068ZsgIFdYaSSF8f3+HYpMoZ6RZcYLtQvJ+96fk=; b=W7yAb/C+6K6lbiArSOkWmUWyO8gTZjCSjnZ3TeTu9kyYjSV3BkbRNSNIbNXLt8n6cI feARQsLZipeBVNMvc2CpGk0cphUWlCgvbpi0kzKSxwJpzRwIH4b1KnoCpZY5CtOnjR3w 0vG1S4koYvF2wpM7hIajwNdFFy0t976cmNQJvhuefEmxSFiwrge20nohobCKOqh1/4rg 4qs2Qtd1z1ur/X3vf9QdpWABhWhsikb+5BnUZduu6KMAB7PioSwGHPr824jgHn1i769B vbow3Sq9SKsiFLheoPu0D1YLP8xdBR0wgSozKrjSaqkaJ+cfwy6OgNUCNu9LZSTaPGMW D36w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787845125; x=1788449925; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=1WXl068ZsgIFdYaSSF8f3+HYpMoZ6RZcYLtQvJ+96fk=; b=j5u4b0JiB0X7mlllYE8TlscsG6gShF0fqTQIZRNzTguWEGhPzG7H65ldr+hFVuIvrE L1VN0xHqgx6Wlg50hkI/G9tZWZiQGDNUvFTb9RqRNrCXiLuw11R0oPik3FI54j/L7s0k Y1b5YBiCKX9ejSho8NqL/SLmHNHpcnQwLOW7kVDOkoJOlCgxVZeyvKR25Ya0AnCl/H4s ItzoiErCNsSlxNNOMy5WyI4b6l8kZmHyj18tLbEv8c5NCYw6iehv2+vnMWrSCwtkRJ6m Qdk2iDhiCw6NOQcT5gpeW1vz3cZTXPMd1uWZ6M2ud9zRLgYmug2Jn7BbqQhuQ7ahRIOZ bE6g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+Rohr1G+eUi6qn8hlfieUFMzec9tAwvEv0wHJm5q5157E0+fsEgsXiL+z5yLS3HDBb86YNzR0g3Z96F1@gnusha.org X-Gm-Message-State: AFuF++lEMUVQw6bpBmspd0EPtRqhmx1+vjUURmTE6yLxA7M2uw3Vnng2 XkbTd1JnOb6PTffl2CiAWQw4vB6y8SSCNjE2hfcRLaRsSKNtKnLvo6GU X-Received: by 2002:a05:6820:5712:10b0:6b1:3552:3195 with SMTP id 006d021491bc7-6b1a03cca30mr11749376eaf.11.1787845124829; Thu, 27 Aug 2026 08:38:44 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfryVmFwtgzQs7FRhDmpeXSVuLQbHI3hO30zXDuIatx6g==" Received: by 2002:a05:687c:41ce:10b0:456:775f:719f with SMTP id 586e51a60fabf-4670ff8b442ls723660fac.0.-pod-prod-08-us; Thu, 27 Aug 2026 08:38:39 -0700 (PDT) X-Received: by 2002:a05:6808:1202:b0:4b3:1a95:42d8 with SMTP id 5614622812f47-4b3669ece7cmr17012251b6e.8.1787845119574; Thu, 27 Aug 2026 08:38:39 -0700 (PDT) Received: by 2002:a05:690c:442a:b0:848:c909:19b5 with SMTP id 00721157ae682-85752b6bfadms7b3; Wed, 26 Aug 2026 22:52:39 -0700 (PDT) X-Received: by 2002:a05:690c:c6c9:b0:854:d9d0:467b with SMTP id 00721157ae682-85741730018mr43329617b3.22.1787809958873; Wed, 26 Aug 2026 22:52:38 -0700 (PDT) Date: Wed, 26 Aug 2026 22:52:38 -0700 (PDT) From: Liam Gilligan To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <547ADFCA-2BB1-4E16-A26A-C92262EBBD84@gmail.com> Subject: Re: [bitcoindev] A Post-Quantum Path for BIP 324 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_377342_936685418.1787809958526" 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_377342_936685418.1787809958526 Content-Type: multipart/alternative; boundary="----=_Part_377343_1524399383.1787809958526" ------=_Part_377343_1524399383.1787809958526 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey everyone, I agree with Laolu that P2P is the logical first step for PQ migration. TL;DR (uses the terminology below): The need for PQ-P2P is inevitable, and= =20 CTU seems like the best way forward to me. Work should begin by defining=20 how transport upgrades are negotiated. I'd like to establish some terms and acronyms to make discussion a little= =20 bit easier: - CTU (classical-then-upgrade): This is option 1 as laid out by Laolu.= =20 In short, first performing ECDH and then negotiating and (optionally)=20 performing a PQ key exchange over the classically encrypted channel. - OSH (one-shot hybrid): This is option 2 as laid out by Laolu.=20 Basically concatenating the PQ KEM keys/ciphertext to the ECDH keys. As= =20 previously discussed, this can be done with various encodings (such as= =20 Kemeleon and/or an OEINC) to preserve the pseudorandom bytestream 324=20 currently guarantees. - PQ-P2P (post-quantum peer-to-peer) - CRQC (cryptographically relevant quantum computer) - HNDL (harvest now, decrypt later): Recording classically encrypted=20 traffic with the intention of decrypting it with a CRQC later. What problem does PQ-P2P solve?=20 In other words, what features/improvements introduced by BIP-324 are=20 negated by a CRQC? Well, the properties BIP-324 seeks to achieve are as=20 follows[1]: - *Confidentiality against passive attacks*: A passive attacker having= =20 recorded a v2 P2P bytestream (without timing and fragmentation informati= on)=20 must not be able to determine the plaintext being exchanged by the nodes= . - *Observability of active attacks*: A session ID identifying the=20 encrypted channel uniquely is derived deterministically from a=20 Diffie-Hellman negotiation. An active man-in-the-middle attacker is forc= ed=20 to incur a risk of being detected as peer operators can compare session = IDs=20 manually, or using optional authentication methods possibly introduced i= n=20 future protocol versions. - *Pseudorandom bytestream*: A passive attacker having recorded a v2 P2P= =20 bytestream (without timing information and fragmentation information) mu= st=20 not be able to distinguish it from a uniformly random bytestream. - *Shapable bytestream*: It should be possible to shape the bytestream= =20 to increase resistance to traffic analysis (for example, to conceal bloc= k=20 propagation), or censorship avoidance[2]. - *Forward secrecy*: An eavesdropping attacker who compromises a peer's= =20 sessions secrets should not be able to decrypt past session traffic, exc= ept=20 for the latest few packets. - *Upgradability*: The proposal provides an upgrade path using transport= =20 versioning which can be used to add features like authentication, PQC=20 handshake upgrade, etc. in the future. - *Compatibility*: v2 clients will allow inbound v1 connections to=20 minimize risk of network partitions. - *Low overhead*: the introduction of a new P2P transport protocol=20 should not substantially increase computational cost or bandwidth for no= des=20 that implement it, compared to the current protocol. The shapable bytestream, upgradability, compatibility, and low overhead=20 properties are intrinsic to the design and are not affected by the=20 existence of a CRQC. However, the other four properties are violated: *Confidentiality against passive attacks*: A CRQC can break ECDH, and=20 therefore can passively determine the plaintext exchanged. *Observability of active attacks*: An active attacker armed with a CRQC can= =20 relay both nodes' ElligatorSwift encodings unmodified, causing both to=20 derive the same session ID. It can then recover either node's ephemeral=20 private key from the recorded encoding and compute that same shared secret,= =20 allowing it to read and modify traffic while both operators see matching=20 session IDs. *Pseudorandom bytestream*: This follows from confidentiality against=20 passive attacks being violated.[3] *Forward secrecy*: This follows from confidentiality against passive=20 attacks being violated[3]. Arguments against introducing PQ-P2P (and counterarguments)=20 We've established that some of the goals of BIP-324 are clearly defeated by= =20 a quantum attacker, but does that actually *matter*? Consider the pseudorandom bytestream property. We established that a=20 quantum attacker can distinguish a recorded v2 P2P bytestream from a=20 uniformly random bytestream. However, the reason BIP-324 seeks to create a= =20 pseudorandom bytestream is to raise the cost of fingerprinting and=20 censorship[4], and it admits that methods such as timing or port analysis= =20 can fingerprint node traffic. Does a CRQC meaningfully lower the cost of=20 fingerprinting or censorship? It is hard to imagine a world where running= =20 Shor's is cheaper than timing analysis, so it is safe to say that the=20 pseudorandom bytestream still achieves its goal of raising fingerprinting= =20 costs, even in light of a CRQC. Next, consider the observability of active attacks. Ignoring CRQCs briefly,= =20 the only way node operators can detect a MitM to begin with is by=20 communicating their session IDs on an authenticated channel (otherwise it= =20 is still susceptible to a MitM), and thus must be done out of band.=20 Basically, BIP-324 enables MitM detection but provides no means of doing=20 so. AFAIK, no one compares session IDs out of band, and in any case the=20 proportion of nodes that do so is near zero. This failure is more so a=20 reason to introduce some sort of authentication scheme[5] than it is a=20 reason to introduce PQ-P2P. Now, let's talk forward secrecy. As mentioned in [3], the rekey mechanism= =20 itself *could* be secure against a CRQC, but in any case, because=20 confidentiality against passive attacks is violated, it hardly matters. Finally, confidentiality against passive attacks. The most obviously=20 sensitive information in the stream is the origin of transactions[6]. Now,= =20 we'll approach this in a way similar to how we approached the pseudorandom= =20 bytestream. ECDH acts to raise the cost of a passive attack on=20 confidentiality (an effectively infinite cost without a CRQC), but again=20 does nothing for confidentiality against an active attacker. This means=20 that encryption does nothing to hide the origin of a transaction against a= =20 MitM or Sybil[7] attack. Can we imagine a world in which running Shor's is= =20 cheaper than simply MitMing? Can we even imagine a world in which Shor's is= =20 cheaper than Sybiling? This seems like an argument for simply using private= =20 broadcast[8]. That last point does not take into account a HNDL attack. HNDL attacks are= =20 presently far cheaper than any active attacks, as an attacker need only=20 record traffic. Importantly, it means the origin of all future transactions= =20 broadcast through v2 can be determined, and it is likely that such an=20 attack is currently taking place. Private broadcast does defeat a HNDL=20 attack on the transactions of nodes that opt in to it, but it is off by=20 default and does nothing for the traffic a node relays on behalf of others.= =20 Moreover, this shouldn't be interpreted as a fix for the lack of=20 confidentiality that v2 traffic has in light of a quantum computer: it is= =20 only used for sendrawtransaction, and does nothing for the confidentiality= =20 of other traffic. Broken encryption can only be fixed with working=20 encryption. As far as the pseudorandom bytestream, observability of active attacks, and= =20 forward secrecy go, I do genuinely think there is not much to be=20 empirically gained by introducing PQ-P2P. However, the argument that cheaper active attacks against confidentiality= =20 exist is an argument for authentication, not an argument against PQ-P2P.=20 Confidentiality can be defeated both by breaking the encryption and by=20 bypassing it entirely (via MitM or Sybil attacks), and the solution is to= =20 fix both. It is theoretically possible that a CRQC can crack ECDLP in=20 minutes[9], and an encryption scheme that can be broken in minutes is not= =20 permissible regardless of what cheaper bypasses exist. With this in mind, it is clear that PQ-P2P is needed. Thoughts on CTU vs OSH=20 I agree with previous discussion that CTU is the appropriate upgrade path,= =20 for the following reasons: 1. DoS surface: OSH requires nodes to read and validate large PQ keys=20 from peers before knowing anything about them, and to generate keys for= =20 every outgoing connection before knowing whether the peer supports PQ at= =20 all. CTU only does so after negotiation. 2. Pseudorandom bytestream: CTU preserves the property at zero cost,=20 because the PQ material is already inside the encrypted channel. OSH mus= t=20 additionally implement Kemeleon, and arguably an OEINC combiner, purely = to=20 avoid regressing it. 3. Extension rather than replacement: CTU extends BIP-324, whereas OSH= =20 replaces it and would require a new transport version. The only real gain from an OSH solution is reducing round trips, which I=20 don't think is valuable enough to sacrifice the benefits CTU offers. I think specifying how transport upgrades are negotiated at all is the=20 logical first step, and it should be defined such that different PQ-KEMs=20 can be negotiated, as well as authentication protocols (authentication=20 solves other P2P problems discussed elsewhere). I'll follow up with a=20 concrete proposal in a separate thread. I'd like to hear what you all think. Best, Liam ------------------------------ [1] https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#goals [2]=20 https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#cite_note-sh= apable_hs_tor_circumvention_4 [3] Forward secrecy is currently achieved by deterministically generating= =20 new keys every 224 messages. This does not protect future messages, but=20 means an attacker with access to intermediary keys (i.e., not the shared=20 secret derived from ECDH or the key it produces) cannot derive previous=20 keys and decrypt past messages. Given an intermediary key, it is not=20 immediately clear to me how an attacker could use a CRQC to find a previous= =20 key, but it hardly matters: if they recorded past messages they wish to=20 decrypt, then they likely also recorded the handshake, and can break the=20 initial ECDH from there and can therefore decrypt all traffic. However,=20 assuming an attacker armed with a CRQC discovers an intermediary key but=20 has not recorded the handshake, then I suppose forward secrecy would be=20 preserved. [4] "A pseudorandom bytestream excludes identification techniques based on= =20 pattern matching, and makes it easier to shape the bytestream in order to= =20 mimic other protocols used on the Internet. This raises the cost of a=20 connection censoring firewall, forcing them to either resort to a full MitM= =20 attack, or operate on a more obvious allowlist basis, rather than a=20 blocklist basis." -- BIP-324 Motivation,=20 https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#motivation [5] See sipa's post on Countersign and other private authentication=20 protocols: https://wuille.net/posts/private-authentication-protocols/ [6] Relay timing, block and filter requests, and addr gossip are all part= =20 of the stream, not only transaction announcements. [7] https://en.wikipedia.org/wiki/Sybil_attack [8] https://github.com/bitcoin/bitcoin/pull/29415 [9] https://arxiv.org/abs/2603.28846 -- note the runtime estimate carries= =20 significant caveats around qubit counts and hardware architecture; see the= =20 paper for details. On Saturday, May 9, 2026 at 9:39:13=E2=80=AFAM UTC conduition wrote: > Oopsie, I just saw Laolu's footnote #4 about ignoring isogeny crypto.=20 > Guess I should learn to read better :P > > regards, > conduition > On Friday, May 8th, 2026 at 8:21 PM, conduition =20 > wrote: > > Hi all, > > I'm not well-versed in the P2P network transport protocol or BIP324, so= =20 > I'm not well-qualified to give feedback on the details of this idea. But = I=20 > did want to chime in on this statement: > > One thing worth noting is that AFAICT, so far in the NIST PQC world [4],= =20 > there is no known non-interactive key exchange protocol like we enjoy=20 > today with ECDH. IIUC, the reason is that lattice based schemes derived= =20 > from the LWE [3] problem, whose security is predicated on using "noise" t= o=20 > hide a secret value. For these cryptosystems, usually a type of "hint" is= =20 > sent to make everything work out nicely like in ECDH. However, in the=20 > stricter non-interactive setting (no messages sent), this doesn't map=20 > cleanly.=20 > > > It's important to emphasize this only considers the NIST-standardized=20 > KEMs. If we zoom out to the broader ecosystem of PQ PKE candidates, there= =20 > are several options for non-interactive key exchange systems that'd be a= =20 > drop-in replacement for ECDH. > > For instance, oriented isogeny-based systems like CSIDH [1] [2] permit=20 > this kind of construction. Both parties publish a short (64 to 128 byte)= =20 > pubkey and can perform key exchange as soon as they've seen the peer's=20 > pubkey, no additional messages required. The down side of CSIDH is that= =20 > it's quite slow, so it is most useful when pubkeys are static or otherwis= e=20 > don't change much. There has been a lot of work done with new faster=20 > schemes [3] or speeding up CSIDH with better implementations [4] but=20 > still key exchange can take a good few dozen milliseconds.=20 > > In general, any post-quantum-secure commutative group action scheme allow= s=20 > non-interactive key exchange. CSIDH is just one such example, and I'm sur= e=20 > there are and will be others. > > Being unversed in BIP324 as yet, I'm not sure how crucial this=20 > non-interactivity property is to the protocol. If it's not a big deal, th= en=20 > I'd gladly toss my hat in for lattices and a hybridized ML-KEM=20 > construction, given so much of the internet is already migrating to this.= =20 > It makes sense to follow standards if we can. Going full-TLS would probab= ly=20 > be overkill IMO - It is designed for a very different (centralized) PKI= =20 > architecture and would buy us a ticket for a train we probably don't want= =20 > to ride. > > Maybe there's a more applicable standard, a la Noise/Wireguard? For a=20 > possible implementation reference, see [5]. Otherwise rolling our own=20 > standard seems like the way to go, especially if we can do so in a way th= at=20 > is reusable for other use-cases beyond Bitcoin. > > Also, if we go with a hybrid scheme, we should have clear migration paths= =20 > to transition to either pure PQC (if a CRQC appears and breaks ECDH, we= =20 > might as well discard it), or back to classical ECDH (if CRQCs turn out t= o=20 > be impossible). > > regards, > conduition > > [1]: https://csidh.isogeny.org/ > [2]: https://eprint.iacr.org/2018/383 > [3]: https://eprint.iacr.org/2025/1098.pdf > [4]: https://ctidh.isogeny.org/ctidh-20210513.pdf > [5]: https://github.com/jmlepisto/clatter > > > > On Thursday, May 7th, 2026 at 1:45 AM, Jonas Schnelli < > jonas.s...@gmail.com> wrote: > > Thanks for writing this up Laolu. > > I think option 1 (classical-then-PQ-upgrade) is probably the right path,= =20 > mostly because it keeps the byte-0 pseudorandomness property without=20 > needing Kemeleon or any new obfuscation primitive. > > If the ML-KEM exchange happens inside the already-established v2=20 > ChaCha20Poly1305 channel, then to a present-day classical observer the=20 > bytes should still look random,... the inner PQ handshake is just more=20 > ciphertext. A future QC adversary doing harvest-now-decrypt-later would= =20 > break the outer ECDH eventually, but I think they'd then still have to=20 > break ML-KEM-768 to get the v3 transport keys, which is kind of the whole= =20 > point. So we'd probably get hybrid security against the QC threat and als= o=20 > keep the property that today's wire bytes are indistinguishable from rand= om. > > That said, I'm not sure how far we should really take the pseudorandomnes= s=20 > argument,... traffic shape (packet sizes, timings, query/response pattern= s)=20 > probably already reveals quite a bit about what's going on, so the=20 > byte-content randomness is only one part of the picture. > > The extra round trip is probably fine given how long Bitcoin P2P=20 > connections live. The DoS angle you flagged might also be smaller in opti= on=20 > 1, since the responder still commits after 64 bytes and not after a=20 > 1184-byte ML-KEM key,... though I haven't thought hard about wether there= =20 > are other DoS vectors the inner upgrade introduces. > > On Ethan's TLS 1.3 suggestionm,... I don't think it really fits. Apart=20 > from the dependency cost (which we deliberately kept low in BIP 324), TLS= =20 > has it's own fingerprint, which would probably undo the=20 > censorship-resistance angle. And it bundles authentication with encryptio= n,=20 > which we explicitly decoupled. > > One thing worth looking at: OpenSSH (whose chacha20-poly1305 construction= =20 > we drew from originally) shipped mlkem768x25519-sha256 as default in 10.0= =20 > last year, and they just concatenate-and-hash the two shared secrets. The= ir=20 > threat model doesn't care about pseudorandomness so they can send ML-KEM= =20 > material in the clear, but the combiner shape is probably a reasonable=20 > reference for ours. > > /jonas > > On May 6, 2026, at 12:15=E2=80=AFPM, Olaoluwa Osuntokun wrote: > > Hi Ethan,=20 > > That's a great question.=20 > > First, I don't speak for Bitcoin Core by any means (btcd has also=20 > implemented > BIP 324 FWIW). Based on past observed behavior, they typically prefer to= =20 > keep > dependencies slim. Many years ago there was a concerted push to remove=20 > openssl > as a dependency from the project. So I would imagine the idea of rolling= =20 > out > full blown TLS 1.3 might encounter some resistance. > > In terms of cryptography, BIP 324 as defined uses secp256k1. TLS 1.3 as > specified doesn't support secp256k1 within the set of supported cipher=20 > 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 hybrid PQ KEM, there exists an IETF to add a new key agreemen= t > suite to TLS 1.3:=20 > https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/. > Only secp256+384(r1) and x25519 are supported as elliptic curves in this= =20 > draft. > > One additional aspect is that today BIP 324 doesn't implement=20 > authentication at > all, you only get confidentiality. TLS 1.3 would mean introducing=20 > certificates > in some fashion, thereby coupling concerns from the original PoV of Bip= =20 > 324. > > BIP 324 also includes as section in the BIP detailing the rationale of BI= P=20 > 324 > over a more general purpose protocol (mentions some of the points above): > > https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#:~:text=3D= Why%20not%20use%20a%20general%2Dpurpose%20transport%20encryption%20protocol= %3F > . > > > -- Laolu > > > > On Tue, May 5, 2026 at 2:18=E2=80=AFPM Ethan Heilman w= rote: > >> Thanks Laolu for thinking through making PQ BIP 324 and writing this up. >> >> Reading through what you wrote made me what wonder, why not use this as= =20 >> an opportunity to move to TLS 1.3? >> >> What's the case against using TLS 1.3 for PQ P2P connection encryption?= =20 >> Is there some functionality that TLS 1.3 is lacking that we really want?= =20 >> Is the case against solely to not have TLS 1.3 as a complex dependency i= n=20 >> bitcoin-core? >> >> The advantages of TLS 1.3: >> >> 1. Make Bitcoin P2P connections blend in with all the other TLS=20 >> connections. This isn't strong privacy, you can distinguish TLS encrypte= d=20 >> Bitcoin traffic via timing and size, but it reduces accidents where a=20 >> firewall sees an unknown protocol and blocks it. >> >> 2. Use of QUIC for faster relay, oblivious HTTP and QUIC=20 >> 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. >> >> >> On Tue, May 5, 2026, 00:41 Olaoluwa Osuntokun wrote: >> >>> Hi y'all,=20 >>> >>> In case you weren't already tired of all the recent dev list chatter re= =20 >>> post >>> quantum cryptography, here's another! >>> >>> When the topic of Bitcoin transitioning to a post quantum world is=20 >>> brought up, >>> the discussion typically focuses on the consensus layer re swapping out >>> vulnerable signature schemes. However, the consensus layer isn't the=20 >>> only area >>> of Bitcoin that relies in cryptography that would be broken in the face= =20 >>> of a >>> powerful quantum computer! That's right, I'm talking about BIP 324, the= =20 >>> peer to >>> peer encryption BIP for Bitcoin. >>> >>> Like everything else on the Internet today, BIP 324 uses ECDH to allow= =20 >>> two >>> connecting peers to derive a shared secret known only to them, which is= =20 >>> then >>> used to encrypt all traffic between them. As ECDH relies on Elliptic=20 >>> Curve >>> cryptography, a future quantum computer would be able to eavesdrop on a= =20 >>> p2p >>> handshake transcript, then derive the underlying private keys to the=20 >>> ephemeral >>> ECDH public key, permitting it to decrypt all traffic. It's actually=20 >>> worse than >>> that, as today adversaries can collect all encrypted p2p Bitcoin=20 >>> traffic, with >>> the hope of being able to decrypt it all at a future date. This is=20 >>> commonly >>> referred to as the: "harvest, decrypt later" (HNDL) strategy [11]. >>> >>> Compared to a consensus change, which requires widespread market=20 >>> agreement, and >>> coordination to achieve, upgrading BIP 324 to be post quantum resistant= =20 >>> is a >>> much lower hanging fruit worthy of pursing immediately. >>> >>> Last week I starting thinking a bit about this topic, brushing up on th= e=20 >>> latest >>> literature/techniques, and stumbled onto a few key design questions. Th= e=20 >>> goal >>> of this post isn't to propose a new concrete p2p encryption BIP, instea= d=20 >>> I want >>> to start discussion on the various design tradeoffs that came up as I w= as >>> researching this p2p encryption transition. >>> >>> ## PQ BIP 324 Design Questions >>> >>> 1. Do we want to pursue a hybrid KEM (key encapsulation mechanism), or= =20 >>> 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=20 >>> classical-then-pq-upgrade, >>> or a one shot hybrid oblivious KEM. >>> >>> >>> ## A Brief Intro 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 o= n=20 >>> the >>> tin, ML-KEM is a lattice based Key-Encapsulation Mechanism. The phrase= =20 >>> KEM >>> might sound unfamiliar with those comfortable with ECDH, but ECDH is=20 >>> actually a >>> KEM itself. >>> >>> A KEM has 3 algorithms: >>> * KeyGen() -> {sk, pk} >>> * Generates a public/private secret key pair >>> >>> * Encaps(pub) -> {secret, capsule} >>> * Generates a new secret value, and a "capsule", which only the=20 >>> holder of >>> 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= =20 >>> elegant >>> one at that: >>> * KeyGen() -> {k, k*G} >>> * Normal EC key generation.=20 >>> >>> * Encaps(pub) -> {capsule =3D x*G, secret =3D pub*x} >>> * The core ECDH routine. The ephemeral public key is actually the >>> "capsule". The resulting secret is the ECDH output with the=20 >>> remote >>> party's KEM public key and the local secret. >>> >>> * Decaps(priv, capsule) -> secret =3D priv * capsule >>> * The receiver completes the key exchange using the ephemeral=20 >>> public key >>> and their own private key. >>> >>> ECIES is another flavor of EC based KEM. >>> >>> One thing worth noting is that AFAICT, so far in the NIST PQC world [4]= ,=20 >>> there is >>> no known non-interactive key exchange protocol like we enjoy today with= =20 >>> ECDH. >>> IIUC, the reason is that lattice based schemes derived from the LWE [3] >>> problem, whose security is predicated on using "noise" to hide a secret= =20 >>> value. >>> For these cryptosystems, usually a type of "hint" is sent to make=20 >>> everything >>> work out nicely like in ECDH. However, in the stricter non-interactive= =20 >>> 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 question.... >>> >>> Should we use a hybrid KEM or a pure post quantum one?=20 >>> >>> A hybrid KEM would keep the existing ECDH, _also_ do ML-KEM, then=20 >>> securely >>> combine (there's some subtlety there, see [6][7]) the resulting in a >>> final secret value for encryption. A hybrid KEM is attractive as an=20 >>> encryption >>> channel derived from such a KEM is secure if _any_ of the combined=20 >>> schemes are >>> secure. This permits schemes to hedge a bit, as hey, maybe the PQ stuff= =20 >>> is >>> actually broken in the future but ECDH isn't. If it's the other way=20 >>> around, >>> then your encryption scheme is still secure. >>> >>> ### Pure ML-KEM P2P Encrypted Handshake >>> >>> If we opt to not use a hybrid scheme, then the Elligator layer can be= =20 >>> dropped >>> all together. Instead, the 1.1 KB (ML-KEM-768) encapsulation keys are= =20 >>> sent, >>> keeping the trailing garbage+terminator in tact.=20 >>> >>> The initial handshake would look something like:=20 >>> * Alice -> Bob: alice_encaps || initiator_garbage >>> * Alice derives an encapsulation key, and sends it to Bob. >>> >>> * Bob -> Alice: ml_kem_capsule || responder_garbage ||=20 >>> responder_garbage_terminator || first_encrypted_packet >>> * Bob uses Alice's encapsulation key to encapsulate a random secret,= =20 >>> and >>> sends it over to Alice. He can also encrypt the first message at= =20 >>> this >>> point. >>> >>> * Alice -> Bob: initiator_garbage_terminator || first_encrypted_packet >>> * Alice de-encapsulates the shared secret, and can now also start to= =20 >>> encrypt >>> messages. >>> >>> We'd then replace `v2_ecdh` with something like a `v3_mlkem` that=20 >>> derives the >>> final shared secret based on the sent/received transcript up until that= =20 >>> point: >>> * `sha256_tagged("bip324_ml_kem", ml_kem_secret, alice_encaps,=20 >>> ml_kem_capsule)` >>> >>> ### Hybrid ML-KEM P2P Encrypted Handshake >>> >>> If we want to use a hybrid combiner, then along side the normal ellswif= t=20 >>> keys, >>> the ML-KEM-768 encap key is also sent: >>> >>> * Alice -> Bob: ellswift_alice || alice_encaps || initiator_garbage >>> * Bob -> Alice: ellswift_bob || ml_kem_capsule || responder_garbage ||= =20 >>> responder_garbage_terminator || first_encrypted_packet >>> * Alice -> Bob: initiator_garbage_terminator || first_encrypted_packet >>> >>> Then following guidelines of [7], we'd then replace `v2_ecdh` with=20 >>> something >>> like `v3_hybrid_shared_secret`: >>> * `sha256_tagged("bip324_ellswift_xonly_ecdh_mlkem_768", ml_kem_ss,= =20 >>> ecdh_point_x32, alice_encaps, ml_kem_capsule, ellswift_alice, ellswift_= bob)` >>> >>> ## PQ/Hybrid Obfuscated KEMs >>> >>> At this point, those that are familiar with BIP 324 will recognize that= =20 >>> both >>> the pure PQ and hybrid versions renders the ElligatorSwift usage pretty= =20 >>> much >>> useless. ElligatorSwift encodes a 32-byte public key as a 64-byte value= =20 >>> which >>> is indistinguishable from a uniformly distributed bitstream. In a=20 >>> bubble, this >>> means that the initial BIP 324 handshake to a 3rd party observer just= =20 >>> 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 key has >>> identifiable structure, as it's a giant vector of polynomial=20 >>> coefficients mod >>> 3329, which is easily recognizable over the wire. >>> >>> Luckily, there's an ML-KEM analogue to ElligatorSwift, called Kemeleon >>> [8][9][10]! In a similar fashion to ElligatorSwift, it takes an ML-KEM= =20 >>> public >>> key, then encodes it as one giant integer, utilizing rejection sampling= . >>> Kemeleon applies this mapping both to the encapsulation keys, and also= =20 >>> the >>> capsule ciphertext that encrypts the shared secrets. The ML-KEM keys en= d=20 >>> up >>> being a bit smaller, while the ciphertexts map to a larger value. Anoth= er >>> tradeoff is that the Kemeleon key generation is ~3x slower than normal= =20 >>> ML-KEM >>> generation. >>> >>> One thing to note here is that Kemeleon's "looks random" property isn't= =20 >>> quite >>> on the same footing as ElligatorSwift's. ElligatorSwift is statisticall= y >>> indistinguishable from random, since every 512-bit string is a valid=20 >>> encoding. >>> Kemeleon's indistinguishability is computational, resting on a Module-L= WE >>> style assumption. So if you naively concatenate an ElligatorSwift key= =20 >>> and a >>> Kemeleon key, the pair is only as obfuscated as the weakest visible=20 >>> half. This >>> asymmetry is what motivates the OEINC construction discussed below. >>> >>> This brings us to our second design question.... >>> >>> Do we still want to ensure that the BIP-324 handshake looks identical t= o=20 >>> a >>> pseudorandom bytestream from the very first message? >>> >>> Assuming yes, then AFAICT, we have two classes of options here:=20 >>> 1. Retain the existing BIP-324 outer ElligatorSwift handshake, but=20 >>> use ML-KEM >>> within that initial encrypted transport to upgrade to a PQ shared= =20 >>> secret. >>> >>> 2. Use the Outer Encrypts Inner Nested Combiner (OEINC - "OINK")=20 >>> combiner >>> from [8]. >>> >>> 3. Attempt to adapt Drivel from [8] into the Bitcoin p2p setting. >>> >>> ### Classical Encrypted Channel Upgrades to PQ >>> >>> With the first option, we simply use one KEM right after the other. So= =20 >>> BIP 324 >>> v2 would be mostly unchanged, then we _upgrade_ to BIP 324 v3 within v2= . >>> =20 >>> >>> A sketch of this would be something like: >>> * Phase 0: normal 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 scheme. >>> * Before this point, no Bitcoin p2p message should be sent, as the= =20 >>> channel >>> isn't PQC protected yet. >>> * Phase 2: do normal ML-KEM within the ElligatorSwift derived=20 >>> 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 use a hybrid combiner like sketched out above= =20 >>> to derive >>> a new set of transport keys >>> * Phase 4: both sides rekey, switching over to a new the transport=20 >>> keys >>> >>> The upside of this option is that the outer part of BIP 324 remains=20 >>> unchanged, >>> then with another round trip, we're able to upgrade the encryption keys= =20 >>> to PQ >>> hybrid security. The downside is that the very first messages sent=20 >>> aren't PQ >>> from the start, but a PQ adversary wouldn't be able to decrypt the actu= al >>> Bitcoin p2p messages (as we wait to send those until the upgrade). The >>> handshake still looks like just random bytes. >>> >>> ### Outer Encrypts Inner Nested Combiner >>> >>> For the second option, [8] (with talk video [9] and slides [10])=20 >>> describes an >>> OEINC scheme where the outer KEM >>> encrypts the inner KEM, wherein the KEM ciphertext of an inner KEM is= =20 >>> encrypted >>> using a shared secret derived from the outer KEM. The two KEM=20 >>> ciphertexts and >>> the two derived keys are then used alongside a hybrid combiner to deriv= e=20 >>> a >>> final shared secret.=20 >>> >>> Unlike the classical-then-pq-upgrade that establishes a classical=20 >>> channel, then >>> uses that to upgrade to pq channel, OEINC is a special hybrid combiner= =20 >>> that >>> achieves a similar output but in one swoop. It defines a special KEM,= =20 >>> which can >>> then be used as the KEM in the very first handshake I sketched out. >>> >>> A sketch of this KEM looks something like: >>> * Setup: >>> * The outer KEM is BIP 324's ElligatorSwift-encoded secp256k1 DHKEM= . >>> * It serves as the outer KEM because its on-wire encoding is >>> statistically indistinguishable from random. >>> * The inner KEM is ML-Kemeleon. >>> >>> * KeyGen(): >>> * (kem_secret_outer, kem_pubkey_outer) =3D outKEM.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_secret_inner) >>> >>> * Encaps(combined_pubkey): >>> * (shared_secret_outer, capsule_outer) =3D=20 >>> outKEM.Encap(kem_pubkey_outer) >>> * (encrypt_key_1, encrypt_key_2) =3D KDF(shared_secret_outer) >>> * (shared_secret_inner, capsule_inner) =3D=20 >>> inKEM.Encap(kem_pubkey_inner) >>> * encrypted_capsule_inner =3D encrypt(encrypt_key_1, capsule_inner) >>> * combined_capsule =3D capsule_outer || encrypted_capsule_inner >>> * combined_shared_secret =3D combine(encrypt_key_2,=20 >>> shared_secret_inner, combined_capsule) >>> >>> * Decaps(combined_secret, combined_capsule): >>> * (capsule_outer, encrypted_capsule_inner) =3D combined_capsule >>> * shared_secret_outer =3D outKEM.Decaps(kem_secret_outer,=20 >>> capsule_outer) >>> * (encrypt_key_1, encrypt_key_2) =3D KDF(shared_secret_outer) >>> * capsule_inner =3D decrypt(encrypt_key_1, encrypted_capsule_inner) >>> * shared_secret_inner =3D inKEM.Decaps(kem_secret_inner,=20 >>> capsule_inner) >>> * combined_shared_secret =3D combine(encrypt_key_2,=20 >>> shared_secret_inner, combined_capsule) >>> >>> >>> This is done over just sending the two encapsulated secrets plainly as = I >>> outlined above in order to achieve a stronger security notion. The issu= e=20 >>> with >>> this though is that though ciphertext uniformity (the encapsulated=20 >>> secrets) is >>> achieved, the two public keys sent are randomly looking, but not in a= =20 >>> uniform >>> manner. In practice, this might not really matter much AFAICT (a=20 >>> theoretical >>> adversary would be able to distinguish the Elligator half from the=20 >>> Kemeleon >>> half). >>> >>> ### Drivel: PQ-Obfuscated Authentication >>> >>> The biggest issue with Drivel as a fit for BIP 324 is that it expects t= he >>> initiator to already know a long term static public key for the=20 >>> responder. In >>> the case of BIP 324, only ephemeral keys are exchanged, so there's no= =20 >>> long >>> term public keys known to either side. >>> >>> To get around this, we could extend BIP 155 (or make a new one likely,= =20 >>> given >>> size limits) to include a signed OKEM key. However then that would=20 >>> introduce >>> authentication into the combined set, which explicitly wasn't a design= =20 >>> goal >>> of BIP 324. >>> >>> With that caveat in mind, here's the construction itself. Drivel [8]=20 >>> combines >>> the OEINC scheme with another layer that out-of-the-box assumes an=20 >>> asymmetric >>> protocol within a set client and server. The client uses an existing=20 >>> OEINC >>> KEM public key published by the server to then encrypt a fresh new=20 >>> ephemeral >>> KEM. >>> >>> -----=20 >>> >>> So there we have it. Before drafting a concrete v3 transport, we need t= o >>> decide if we want a hybrid KEM, or are fine with a pure PQ KEM. Then we= =20 >>> need to >>> decide if we want to attempt to maintain the current quality where the= =20 >>> p2p >>> handshake transcript is indistinguishable from random. If yes, then tha= t=20 >>> forces >>> another series of decisions re how to construct/compose an oblivious KE= M=20 >>> from >>> available primitives. >>> >>> At a glance, the route of classical-then-pq-upgrade seems to be the=20 >>> simplest. >>> BIP 324 stays as is, then we run ML-KEM within that. The ML-KEM keys ar= e >>> encrypted, so there's no need to sprinkle in the layer of Kemeleon. >>> >>> If we want a nice combined protocol, then we should investigate the OEI= NC >>> route. It's more data to send as part of the initial handshake, but we= =20 >>> still >>> keep ElligatorSwift 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= =20 >>> also >>> roll out a full blown PQ authentication protocol along side everything. >>> >>> One thing worth flagging for any of the byte-0 designs (where PQ=20 >>> material is >>> sent in the clear on the very first flight, like the hybrid and OEINC= =20 >>> sketches >>> above): ML-KEM-768 makes the responder do real work before it can decid= e=20 >>> if a >>> connection is even legit. Today, the responder only needs the first 64= =20 >>> 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=20 >>> encapsulation >>> key before running Encaps, and FIPS 203 mandates input checks on every= =20 >>> Encaps >>> and Decaps. In a permissionless P2P network, that's a meaningful change= =20 >>> in >>> inbound DoS surface, and probably calls for stricter handshake byte=20 >>> limits, >>> tighter timeouts, and possibly some form of stateless cookie/puzzle if >>> handshake floods become a real problem. The classical-then-pq-upgrade= =20 >>> path >>> sidesteps most of this since the PQ material only shows up after the v2 >>> channel is up. >>> >>> With all that said, after the above design decisions are addressed, the= re >>> aren't too many concrete blockers here w.r.t rolling this out. Of cours= e=20 >>> the >>> development (eg: selecting/creating a library for ML-KEM and maybe >>> ML-Kemeleon), and upgrade will take some time. But unlike the consensus >>> layer, p2p encryption doesn't require the widespread market agreement= =20 >>> that an >>> actual soft fork does. BIP 324 is a much shorter walk to PQ than the=20 >>> consensus >>> layer, and serves as a sort of PQ warm up before the bigger soft fork i= s >>> tackled.=20 >>> >>> >>> -- Laolu >>> >>> [1]: https://en.wikipedia.org/wiki/ML-KEM >>> [2]: https://csrc.nist.gov/pubs/fips/203/final >>> [3]: https://en.wikipedia.org/wiki/Learning_with_errors >>> [4]: This statement ignores Isogeny based crypto, and also SWOOSH [5] a= s=20 >>> 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]:=20 >>> https://csrc.nist.gov/csrc/media/Presentations/2025/kemeleon/images-med= ia/kemeleon.pdf >>> [11]: https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later >>> >>> --=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs9U3prZJiDs0Ns7LSA07= R8hM-GQou_FcTZZz-JUQpUYHw%40mail.gmail.com >>> . >>> >> > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs8i%3DpLP30nRh_iyjSRJX= ne19wNezmQmo%3DJAk8%2BE4uJPhg%40mail.gmail.com > . > > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/547ADFCA-2BB1-4E16-A26A-C922= 62EBBD84%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/= d4b87b2c-63c2-488b-9e76-4e3dbeedb0c2n%40googlegroups.com. ------=_Part_377343_1524399383.1787809958526 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hey everyone,

I agree with Laolu that P2P is the logical first step for PQ migration.<= /p>

TL;DR (uses the terminology below): The need for PQ-P2P is inevitable, a= nd CTU seems like the best way forward to me. Work should begin by defining= how transport upgrades are negotiated.

I'd like to establish some terms and acronyms to make discussion a littl= e bit easier:

  • CTU (classical-then-upgrade): This is option 1 as laid out by Laolu= . In short, first performing ECDH and then negotiating and (optionally) per= forming a PQ key exchange over the classically encrypted channel.
  • O= SH (one-shot hybrid): This is option 2 as laid out by Laolu. Basically conc= atenating the PQ KEM keys/ciphertext to the ECDH keys. As previously discus= sed, this can be done with various encodings (such as Kemeleon and/or an OE= INC) to preserve the pseudorandom bytestream 324 currently guarantees.
    • =
  • PQ-P2P (post-quantum peer-to-peer)
  • CRQC (cryptographically rele= vant quantum computer)
  • HNDL (harvest now, decrypt later): Recording= classically encrypted traffic with the intention of decrypting it with a C= RQC later.
What problem does PQ-P2P solve?

In other words, what features/improvements introduced by BIP-324 are neg= ated by a CRQC? Well, the properties BIP-324 seeks to achieve are as follow= s[1]:

  • Confidentiality against passive attacks: A passive= attacker having recorded a v2 P2P bytestream (without timing and fragmenta= tion information) must not be able to determine the plaintext being exchang= ed by the nodes.
  • Observability of active attacks: = A session ID identifying the encrypted channel uniquely is derived determin= istically from a Diffie-Hellman negotiation. An active man-in-the-middle at= tacker is forced to incur a risk of being detected as peer operators can co= mpare session IDs manually, or using optional authentication methods possib= ly introduced in future protocol versions.
  • Pseudorandom byt= estream: A passive attacker having recorded a v2 P2P bytestream (w= ithout timing information and fragmentation information) must not be able t= o distinguish it from a uniformly random bytestream.
  • Shapab= le bytestream: It should be possible to shape the bytestream to in= crease resistance to traffic analysis (for example, to conceal block propag= ation), or censorship avoidance[2].
  • Forward secrecy: An eavesdropping attacker who compromises a peer's sessions secrets shou= ld not be able to decrypt past session traffic, except for the latest few p= ackets.
  • Upgradability: The proposal provides an up= grade path using transport versioning which can be used to add features lik= e authentication, PQC handshake upgrade, etc. in the future.
  • Compatibility: v2 clients will allow inbound v1 connections to m= inimize risk of network partitions.
  • Low overhead: = the introduction of a new P2P transport protocol should not substantially i= ncrease computational cost or bandwidth for nodes that implement it, compar= ed to the current protocol.

The shapable bytestream, upgradability, compatibility, and low overhead = properties are intrinsic to the design and are not affected by the existenc= e of a CRQC. However, the other four properties are violated:

Confidentiality against passive attacks: A CRQC can bre= ak ECDH, and therefore can passively determine the plaintext exchanged.

Observability of active attacks: An active attacker arm= ed with a CRQC can relay both nodes' ElligatorSwift encodings unmodified, c= ausing both to derive the same session ID. It can then recover either node'= s ephemeral private key from the recorded encoding and compute that same sh= ared secret, allowing it to read and modify traffic while both operators se= e matching session IDs.

Pseudorandom bytestream: This follows from confidential= ity against passive attacks being violated.[3]

Forward secrecy: This follows from confidentiality agai= nst passive attacks being violated[3].

Arguments against introducing PQ-P2P (and counterarguments)

We've established that some of the goals of BIP-324 are clearly defeated= by a quantum attacker, but does that actually matter?

Consider the pseudorandom bytestream property. We established that a qua= ntum attacker can distinguish a recorded v2 P2P bytestream from a uniformly= random bytestream. However, the reason BIP-324 seeks to create a pseudoran= dom bytestream is to raise the cost of fingerprinting and censorship[4], an= d it admits that methods such as timing or port analysis can fingerprint no= de traffic. Does a CRQC meaningfully lower the cost of fingerprinting or ce= nsorship? It is hard to imagine a world where running Shor's is cheaper tha= n timing analysis, so it is safe to say that the pseudorandom bytestream st= ill achieves its goal of raising fingerprinting costs, even in light of a C= RQC.

Next, consider the observability of active attacks. Ignoring CRQCs brief= ly, the only way node operators can detect a MitM to begin with is by commu= nicating their session IDs on an authenticated channel (otherwise it is sti= ll susceptible to a MitM), and thus must be done out of band. Basically, BI= P-324 enables MitM detection but provides no means of doing so. AFAIK, no o= ne compares session IDs out of band, and in any case the proportion of node= s that do so is near zero. This failure is more so a reason to introduce so= me sort of authentication scheme[5] than it is a reason to introduce PQ-P2P= .

Now, let's talk forward secrecy. As mentioned in [3], the rekey mechanis= m itself could be secure against a CRQC, but in any case, because = confidentiality against passive attacks is violated, it hardly matters.

Finally, confidentiality against passive attacks. The most obviously sen= sitive information in the stream is the origin of transactions[6]. Now, we'= ll approach this in a way similar to how we approached the pseudorandom byt= estream. ECDH acts to raise the cost of a passive attack on confidentiality= (an effectively infinite cost without a CRQC), but again does nothing for = confidentiality against an active attacker. This means that encryption does= nothing to hide the origin of a transaction against a MitM or Sybil[7] att= ack. Can we imagine a world in which running Shor's is cheaper than simply = MitMing? Can we even imagine a world in which Shor's is cheaper than Sybili= ng? This seems like an argument for simply using private broadcast[8].

That last point does not take into account a HNDL attack. HNDL attacks a= re presently far cheaper than any active attacks, as an attacker need only = record traffic. Importantly, it means the origin of all future transactions= broadcast through v2 can be determined, and it is likely that such an atta= ck is currently taking place. Private broadcast does defeat a HNDL attack o= n the transactions of nodes that opt in to it, but it is off by default and= does nothing for the traffic a node relays on behalf of others. Moreover, = this shouldn't be interpreted as a fix for the lack of confidentiality that= v2 traffic has in light of a quantum computer: it is only used for s= endrawtransaction, and does nothing for the confidentiality of other= traffic. Broken encryption can only be fixed with working encryption.

As far as the pseudorandom bytestream, observability of active attacks, = and forward secrecy go, I do genuinely think there is not much to be empiri= cally gained by introducing PQ-P2P.

However, the argument that cheaper active attacks against confidentialit= y exist is an argument for authentication, not an argument against PQ-P2P. = Confidentiality can be defeated both by breaking the encryption and by bypa= ssing it entirely (via MitM or Sybil attacks), and the solution is to fix b= oth. It is theoretically possible that a CRQC can crack ECDLP in minutes[9]= , and an encryption scheme that can be broken in minutes is not permissible= regardless of what cheaper bypasses exist.

With this in mind, it is clear that PQ-P2P is needed.

Thoughts on CTU vs OSH

I agree with previous discussion that CTU is the appropriate upgrade pat= h, for the following reasons:

  1. DoS surface: OSH requires nodes to read and validate large PQ keys = from peers before knowing anything about them, and to generate keys for eve= ry outgoing connection before knowing whether the peer supports PQ at all. = CTU only does so after negotiation.
  2. Pseudorandom bytestream: CTU pr= eserves the property at zero cost, because the PQ material is already insid= e the encrypted channel. OSH must additionally implement Kemeleon, and argu= ably an OEINC combiner, purely to avoid regressing it.
  3. Extension ra= ther than replacement: CTU extends BIP-324, whereas OSH replaces it and wou= ld require a new transport version.

The only real gain from an OSH solution is reducing round trips, which I= don't think is valuable enough to sacrifice the benefits CTU offers.

I think specifying how transport upgrades are negotiated at all is the l= ogical first step, and it should be defined such that different PQ-KEMs can= be negotiated, as well as authentication protocols (authentication solves = other P2P problems discussed elsewhere). I'll follow up with a concrete pro= posal in a separate thread.

I'd like to hear what you all think.

Best,
Liam

[1] https://github.com= /bitcoin/bips/blob/master/bip-0324.mediawiki#goals

[2] https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#cite_note-s= hapable_hs_tor_circumvention_4

[3] Forward secrecy is currently a= chieved by deterministically generating new keys every 224 messages. This d= oes not protect future messages, but means an attacker with access to inter= mediary keys (i.e., not the shared secret derived from ECDH or the key it p= roduces) cannot derive previous keys and decrypt past messages. Given an in= termediary key, it is not immediately clear to me how an attacker could use= a CRQC to find a previous key, but it hardly matters: if they recorded pas= t messages they wish to decrypt, then they likely also recorded the handsha= ke, and can break the initial ECDH from there and can therefore decrypt all= traffic. However, assuming an attacker armed with a CRQC discovers an inte= rmediary key but has not recorded the handshake, then I suppose forward sec= recy would be preserved.

[4] "A pseudorandom bytestream excludes iden= tification techniques based on pattern matching, and makes it easier to sha= pe the bytestream in order to mimic other protocols used on the Internet. T= his raises the cost of a connection censoring firewall, forcing them to eit= her resort to a full MitM attack, or operate on a more obvious allowlist ba= sis, rather than a blocklist basis." -- BIP-324 Motivation, https://github.com/bitcoin/bips/blo= b/master/bip-0324.mediawiki#motivation

[5] See sipa's post on Cou= ntersign and other private authentication protocols: https://wuille.net/posts/private-authentication-protocols= /

[6] Relay timing, block and filter requests, and addr gossip ar= e all part of the stream, not only transaction announcements.

[7] https://en.wikipedia.org/wiki/Sybil_attack

[8] https://github.com/bitcoin/bitcoin/pull/294= 15

[9] https://arxiv.org/abs/2603.28846=C2=A0--= note the runtime estimate carries significant caveats around qubit counts = and hardware architecture; see the paper for details.



On Saturday, Ma= y 9, 2026 at 9:39:13=E2=80=AFAM UTC conduition wrote:
Oopsie, I just saw Laolu's footnote #4 about i= gnoring isogeny crypto. Guess I should learn to read better :P

regards,
conduition
On Friday, May 8th, 2026 at 8:21 PM, conduition <condu...@proton.me> wrote:
Hi a= ll,

I'm not w= ell-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 did want= to chime in on this statement:

<= span>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 enjoy today with ECDH. IIUC, the reason is that lattice based schemes d= erived from the LWE [3] problem, whose security is predicated on using &quo= t;noise" to hide a secret value. For these cryptosystems, usually a ty= pe of "hint" is sent to make everything work out nicely like in E= CDH. However, in the stricter non-interactive setting=C2=A0(no messag= es sent), this doesn't map cleanly.=C2=A0
=

It&= #39;s important to emphasize this only considers the NIST-standardized KEMs= . If we zoom out to the broader ecosystem of PQ PKE candidates, there are s= everal options for non-interactive key exchange systems that'd be a dro= p-in replacement for ECDH.

For instance, oriented isogeny-based sy= stems like CSIDH [1] [2] permit this kind of construction. Both parties pub= lish a short (64 to 128 byte) pubkey and can perform key exchange as soon a= s 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 wh= en pubkeys are static or otherwise don't change much. There has been a = lot of work done with new faster schemes=C2=A0[3] or speeding up CSI= DH with better implementations=C2=A0[4] but still key exchange can take a g= ood few dozen milliseconds.=C2=A0

In general, any post-quantum-secure co= mmutative group action scheme allows non-interactive key exchange. CSIDH is= just one such example, and I'm sure there are and will be others.

Being unversed in BIP= 324 as yet, I'm not sure how crucial this non-interactivity property is= to the protocol. If it's not a big deal, then I'd gladly toss my h= at in for lattices and a hybridized ML-KEM construction, given so much of t= he internet is already migrating to this. It makes sense to follow standard= s if we can. Going full-TLS would probably be overkill IMO - It is designed= for a very different (centralized) PKI architecture and would buy us a tic= ket for a train we probably don't want to ride.

Maybe there's a more applicable stan= dard, a la Noise/Wireguard? For a possible 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 reusable for other use-cases beyond Bitcoi= n.

Also, if we go= with a hybrid scheme, we should have clear migration paths to transition t= o either pure PQC (if a CRQC appears and breaks ECDH, we might as well disc= ard it), or back to classical ECDH (if CRQCs turn out to be impossible).

= regards,
conduition

[2]:=C2=A0https://eprint.iacr.org/2018/383
<= br>
<= br>
On Thursday, May 7th, 2026 at 1:45 AM, Jonas Schnelli <jonas.s...@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 hybrid security against the QC threat and also keep the property that t= oday's wire bytes are indistinguishable from random.

That said, I'm not sure how far we should really take the pseudo= randomness argument,... traffic shape (packet sizes, timings, query/respons= e patterns) probably already reveals quite a bit about what's going on,= so the byte-content randomness is only one part of the picture.
=
The extra round trip is probably fine given how long Bitcoin= P2P connections live. The DoS angle you flagged might also be smaller in o= ption 1, since the responder still commits after 64 bytes and not after a 1= 184-byte ML-KEM key,... though I haven't thought hard about wether ther= e are other DoS vectors the inner upgrade introduces.

<= div>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 has it's own fingerprint, which would probably undo the censorsh= ip-resistance angle. And it bundles authentication with encryption, which w= e explicitly decoupled.

One thing worth looking at= : OpenSSH (whose chacha20-poly1305 construction we drew from originally) sh= ipped mlkem768x25519-sha256 as default in 10.0 last year, and they just con= catenate-and-hash the two shared secrets. Their threat model doesn't ca= re about pseudorandomness so they can send ML-KEM material in the clear, bu= t the combiner shape is probably a reasonable reference for ours.

/jonas

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

Hi Ethan,=C2=A0

That's a= great question.=C2=A0

First, I don't speak for Bit= coin Core by any means (btcd has also implemented
BIP 324 FWIW). Based o= n past observed behavior, they typically prefer to keep
dependencies sli= m. Many years ago there was a concerted push to remove openssl
as a depe= ndency from the project. So I would imagine the idea of rolling out
full= blown TLS 1.3 might encounter some resistance.

In terms of cryptogr= aphy, BIP 324 as defined uses secp256k1. TLS 1.3 as
specified doesn'= t support secp256k1 within the set of supported cipher suites.

If en= suring that BIP 324 continues to implement an oblivious KEM is a key
req= uirement, then TLS 1.3 doesn't fit the bill.

Regarding a hybrid = PQ KEM, there exists an IETF to add a new key agreement
suite to TLS 1.3= :=C2=A0https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-ml= kem/.
Only secp256+384(r1) and x25519 are supported as elliptic curv= es in this draft.

One additional aspect is that today BIP 324 doesn&= #39;t implement authentication at
all, you only get confidentiality. TLS= 1.3 would mean introducing certificates
in some fashion, thereby coupli= ng concerns from the original PoV of Bip 324.

BIP 324 also includes = as section in the BIP detailing the rationale of BIP 324
over a more gen= eral purpose protocol (mentions some of the points above):
https://github.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 Eth= an Heilman <eth...@gmail.com> wrote:
Thanks Laolu for thinking through making PQ BIP 324 an= d writing this up.

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

What's= the case against using TLS 1.3 for PQ P2P connection encryption? Is there = some functionality that TLS 1.3 is lacking that we really want?=C2=A0 Is th= e case against solely to not have TLS 1.3 as a complex dependency in bitcoi= n-core?

The advantages of TLS = 1.3:

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

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

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


On Tue= , May 5, 2026, 00:41 Olaoluwa Osuntokun <lao...@gmail.com> wrote:
Hi y'all,=C2=A0

In = case you weren't already tired of all the recent dev list chatter re po= st
quantum cryptography, here's another!

When the topic of Bi= tcoin transitioning to a post quantum world is brought up,
the discussio= n typically focuses on the consensus layer re swapping out
vulnerable si= gnature schemes. However, the consensus layer isn't the only area
of= Bitcoin that relies in cryptography that would be broken in the face of a<= br>powerful quantum computer! That's right, I'm talking about BIP 3= 24, the peer to
peer encryption BIP for Bitcoin.

Like everything = else on the Internet today, BIP 324 uses ECDH to allow two
connecting pe= ers to derive a shared secret known only to them, which is then
used to = encrypt all traffic between them. As ECDH relies on Elliptic Curve
crypt= ography, a future quantum computer would be able to eavesdrop on a p2p
h= andshake transcript, then derive the underlying private keys to the ephemer= al
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 futu= re date. This is commonly
referred to as the: "harvest, decrypt lat= er" (HNDL) strategy [11].

Compared to a consensus change, which= requires widespread market agreement, and
coordination to achieve, upgr= ading BIP 324 to be post quantum resistant is a
much lower hanging fruit= worthy of pursing immediately.

Last week I starting thinking a bit = about this topic, brushing up on the latest
literature/techniques, and s= tumbled onto a few key design questions. The goal
of this post isn't= to propose a new concrete p2p encryption BIP, instead I want
to start d= iscussion on the various design tradeoffs that came up as I was
research= ing this p2p encryption transition.

## PQ BIP 324 Design Questions
1. Do we want to pursue a hybrid KEM (key encapsulation mechanism), o= r go with
=C2=A0 =C2=A0a pure PQ KEM?

2. Is it still a key requir= ement that the initial handshake be
=C2=A0 =C2=A0indistinguishable from = a random byte string?

=C2=A0 =C2=A02a. If yes to the above, then sho= uld we go with classical-then-pq-upgrade,
=C2=A0 =C2=A0or a one shot hyb= rid oblivious KEM.


## A Brief Intro to KEMs + ML-KEM

Firs= t, let's introduce the new primitive we have to work with: ML-KEM
(M= odule-Lattice-Based Key-Encapsulation Mechanism) [1][2]. As it says on the<= br>tin, ML-KEM is a lattice based Key-Encapsulation Mechanism. The phrase K= EM
might sound unfamiliar with those comfortable with ECDH, but ECDH is = actually a
KEM itself.

A KEM has 3 algorithms:
=C2=A0=C2= =A0* KeyGen() -> {sk, pk}
=C2=A0 =C2=A0 =C2=A0* Generates a pu= blic/private secret key pair

=C2=A0=C2=A0* Encaps(pub) = -> {secret, capsule}
=C2=A0 =C2=A0 =C2=A0* Generates a new secret val= ue, and a "capsule", which only the holder of
=C2=A0 =C2=A0 = =C2=A0 =C2=A0pub can use to obtain the secret value.

=C2=A0=C2= =A0* Decaps(priv, capsule) -> secret
=C2=A0 =C2=A0 =C2=A0* Use= s 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<= br>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

=C2=A0=C2=A0* Encaps(pub) -> {capsule =3D= x*G, secret =3D pub*x}
=C2=A0 =C2=A0 =C2=A0=C2=A0* The cor= e ECDH routine. The ephemeral public key is actually the
=C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0"capsule". The resulting secret i= s the ECDH output with the remote
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0party's KEM public key and the local secret.

=C2=A0=C2=A0* Decaps(priv, capsule) -> secret =3D priv * capsule
= =C2=A0 =C2=A0 =C2=A0=C2=A0* The receiver completes the key exc= hange using the ephemeral public key
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0and their own private key.

ECIES is another flavor of E= C based KEM.

One thing worth noting is that AFAICT, so far in the NI= ST PQC world [4], there is
no known non-interactive key exchange protoco= l like we enjoy today with ECDH.
IIUC, the reason is that lattice based = schemes derived from the LWE [3]
problem, whose security is predicated o= n using "noise" to hide a secret value.
For these cryptosystem= s, usually a type of "hint" is sent to make everything
work ou= t nicely like in ECDH. However, in the stricter non-interactive setting
= (no messages sent), this doesn't map cleanly.

As a result, ML-KE= M 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 question....
Should we use a hybrid KEM or a pure post quantum one?=C2=A0

A hybrid KEM would keep the existing ECDH, _also_ do ML-KEM, th= en securely
combine (there's some subtlety there, see [6][7]) the re= sulting in a
final secret value for encryption. A hybrid KEM is attracti= ve as an encryption
channel derived from such a KEM is secure if _any_ o= f the combined 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 way around,
then your encryption scheme is= still secure.

### Pure ML-KEM P2P Encrypted Handshake

If we = opt to not use a hybrid scheme, then the Elligator layer can 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
=
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 sends it to Bo= b.

=C2=A0* Bob -> Alice: ml_kem_capsule || responder_garbage || r= esponder_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 the first m= essage at this
=C2=A0 =C2=A0 =C2=A0point.

=C2=A0* Alice -> Bob= : initiator_garbage_terminator || first_encrypted_packet
=C2=A0 =C2=A0* = Alice de-encapsulates the shared secret, and can now also start to encrypt<= br>=C2=A0 =C2=A0 =C2=A0messages.

We'd then replace `v2_ecdh` wit= h something like a `v3_mlkem` that derives the
final shared secret based= on the sent/received transcript up until that point:
=C2=A0=C2=A0= * `sha256_tagged("bip324_ml_kem", ml_kem_secret, alice_enc= aps, ml_kem_capsule)`

### Hybrid ML-KEM P2P Encrypted Handshake
<= br>If we want to use a hybrid combiner, then along side the normal ellswift= keys,
the ML-KEM-768 encap key is also sent:

=C2=A0* Alice ->= Bob: ellswift_alice || alice_encaps || initiator_garbage
=C2=A0* Bob -&= gt; Alice: ellswift_bob || ml_kem_capsule || responder_garbage || responder= _garbage_terminator || first_encrypted_packet
=C2=A0* Alice -> Bob: i= nitiator_garbage_terminator || first_encrypted_packet

Then following= guidelines of [7], we'd then replace `v2_ecdh` with something
like = `v3_hybrid_shared_secret`:
=C2=A0=C2=A0* `sha256_tagged(&qu= ot;bip324_ellswift_xonly_ecdh_mlkem_768", ml_kem_ss, ecdh_point_x32, a= lice_encaps, ml_kem_capsule, ellswift_alice, ellswift_bob)`

## PQ/Hy= brid Obfuscated KEMs

At this point, those that are familiar with BIP= 324 will recognize that both
the pure PQ and hybrid versions renders th= e ElligatorSwift usage pretty much
useless. ElligatorSwift encodes a 32-= byte public key as a 64-byte value which
is indistinguishable from a uni= formly distributed bitstream. In a bubble, this
means that the initial B= IP 324 handshake to a 3rd party observer just looks
like random bytes. H= owever, with the introduction of ML-KEM, the ML-KEM
encapsulation key is= sent in plaintext over the wire. An ML-KEM key has
identifiable structu= re, as it's a giant vector of polynomial coefficients mod
3329, whic= h is easily recognizable over the wire.

Luckily, there's an ML-K= EM analogue to ElligatorSwift, called Kemeleon
[8][9][10]! In a similar = fashion to ElligatorSwift, it takes an ML-KEM public
key, then encodes i= t as one giant integer, utilizing rejection sampling.
Kemeleon applies t= his mapping both to the encapsulation keys, and also the
capsule ciphert= ext that encrypts the shared secrets. The ML-KEM keys 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 normal ML-KEM
gen= eration.

One thing to note here is that Kemeleon's "looks r= andom" property isn't quite
on the same footing as ElligatorSwi= ft's. ElligatorSwift is statistically
indistinguishable from random,= since every 512-bit string is a valid encoding.
Kemeleon's indistin= guishability is computational, resting on a Module-LWE
style assumption.= So if you naively concatenate an ElligatorSwift key and a
Kemeleon key,= the pair is only as obfuscated as the weakest visible half. This
asymme= try is what motivates the OEINC construction discussed below.

This b= rings us to our second design question....

Do we still want to ensur= e that the BIP-324 handshake looks identical to a
pseudorandom bytestrea= m from the very first message?

Assuming yes, then AFAICT, we have tw= o classes of options here:=C2=A0
=C2=A0=C2=A01= . Retain the existing BIP-324 outer ElligatorSwift handshake, but use ML-KE= M
=C2=A0 =C2=A0 =C2=A0within that initial encrypted transport to upgrade= to a PQ shared secret.

=C2=A0=C2=A02. Use the Outer En= crypts Inner Nested Combiner (OEINC - "OINK") combiner
=C2=A0 = =C2=A0 =C2=A0from [8].

=C2=A0=C2=A03. Attempt to adapt = Drivel from [8] into the Bitcoin p2p setting.

### Classical Encrypte= d Channel Upgrades to PQ

With the first option, we simply use one KE= M right after the other. So BIP 324
v2 would be mostly unchanged, then w= e _upgrade_ to BIP 324 v3 within v2.=C2=A0

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 encrypted handshake
=C2=A0 =C2=A0 =C2=A0* Can be op= tional, if we just pick a set PQ KEM scheme.
=C2=A0 =C2=A0 =C2=A0* Befor= e this point, no Bitcoin p2p message should be sent, as the channel
=C2= =A0 =C2=A0 =C2=A0 =C2=A0isn't PQC protected yet.
=C2=A0=C2=A0<= /span>* Phase 2: do normal ML-KEM within the ElligatorSwift derived encrypt= ed
=C2=A0 =C2=A0=C2=A0transport
=C2=A0 =C2=A0 =C2=A01. A= lice sends the encapsulation key
=C2=A0 =C2=A0 =C2=A02. Bob derives a se= crets, encrypts it using the encapsulation key
=C2=A0 =C2=A0 =C2=A03. Bo= th sides then derive a PQ shared secret, ss_PQ
=C2=A0=C2=A0= * Phase 3: both sides use a hybrid combiner like sketched out above to deri= ve
=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

The upside of 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 PQ
hybrid security. The downside is th= at the very first messages sent aren't PQ
from the start, but a PQ a= dversary wouldn't be able to decrypt the actual
Bitcoin p2p messages= (as we wait to send those until the upgrade). The
handshake still looks= like just random bytes.

### Outer Encrypts Inner Nested Combiner
For the second option, [8] (with talk video [9] and slides [10]) descr= ibes an
OEINC scheme where the outer KEM
encrypts the inner KEM, wher= ein the KEM ciphertext of an inner KEM is encrypted
using a shared secre= t derived from the outer KEM. The two KEM ciphertexts and
the two derive= d keys are then used alongside a hybrid combiner to derive a
final share= d secret.=C2=A0

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

A sketch of this KE= M looks something like:
=C2=A0=C2=A0* Setup:
=C2=A0 =C2= =A0=C2=A0* The outer KEM is BIP 324's ElligatorSwift-encod= ed secp256k1 DHKEM.
=C2=A0 =C2=A0 =C2=A0 =C2=A0* It serves as the outer = KEM because its on-wire encoding is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0st= atistically indistinguishable from random.
=C2=A0 =C2=A0=C2=A0* The inner KEM is ML-Kemeleon.

=C2=A0=C2=A0* KeyGen= ():
=C2=A0 =C2=A0=C2=A0* (kem_secret_outer, kem_pubkey_oute= r) =3D outKEM.Gen()
=C2=A0 =C2=A0=C2=A0* (kem_secret_inner,= kem_pubkey_inner) =3D inKEM.Gen()
=C2=A0 =C2=A0=C2=A0* com= bined_pubkey =3D (kem_pubkey_outer, kem_pubkey_inner)
=C2=A0 =C2=A0=C2=A0* combined_secret =3D (kem_secret_outer, kem_secret_inner)
=C2=A0=C2=A0* Encaps(combined_pubkey):
=C2=A0 =C2=A0=C2=A0* (shared_secret_outer, capsule_outer) =3D outKEM.Encap(ke= m_pubkey_outer)
=C2=A0 =C2=A0=C2=A0* (encrypt_key_1, encryp= t_key_2) =3D KDF(shared_secret_outer)
=C2=A0 =C2=A0=C2=A0* = (shared_secret_inner, capsule_inner) =3D inKEM.Encap(kem_pubkey_inner)
= =C2=A0 =C2=A0=C2=A0* encrypted_capsule_inner =3D encrypt(encry= pt_key_1, capsule_inner)
=C2=A0 =C2=A0=C2=A0* combined_caps= ule =3D capsule_outer || encrypted_capsule_inner
=C2=A0 =C2=A0=C2= =A0* combined_shared_secret =3D combine(encrypt_key_2, shared_secret= _inner, combined_capsule)

=C2=A0=C2=A0* Decaps(combined= _secret, combined_capsule):
=C2=A0 =C2=A0=C2=A0* (capsule_o= uter, encrypted_capsule_inner) =3D combined_capsule
=C2=A0 =C2=A0= =C2=A0* shared_secret_outer =3D outKEM.Decaps(kem_secret_outer, caps= ule_outer)
=C2=A0 =C2=A0=C2=A0* (encrypt_key_1, encrypt_key= _2) =3D KDF(shared_secret_outer)
=C2=A0 =C2=A0=C2=A0* capsu= le_inner =3D decrypt(encrypt_key_1, encrypted_capsule_inner)
=C2=A0 =C2= =A0=C2=A0* shared_secret_inner =3D inKEM.Decaps(kem_secret_inn= er, capsule_inner)
=C2=A0 =C2=A0=C2=A0* combined_shared_sec= ret =3D combine(encrypt_key_2, shared_secret_inner, combined_capsule)

This is done over just sending the two encapsulated secrets plainly a= s I
outlined above in order to achieve a stronger security notion. The i= ssue with
this though is that though ciphertext uniformity (the encapsul= ated 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 E= lligator half from the Kemeleon
half).

### Drivel: PQ-Obfuscated = Authentication

The biggest issue with Drivel as a fit for BIP 324 is= that it expects the
initiator to already know a long term static public= 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 like= ly, given
size limits) to include a signed OKEM key. However then that w= ould introduce
authentication into the combined set, which explicitly wa= sn't a design goal
of BIP 324.

With that caveat in mind, here= 's the construction itself. Drivel [8] combines
the OEINC scheme wit= h another layer that out-of-the-box assumes an asymmetric
protocol withi= n a set client and server. The client uses an existing OEINC
KEM public = key published by the server to then encrypt a fresh new ephemeral
KEM.
-----=C2=A0

So there we have it. Before drafting = a concrete v3 transport, we need to
decide if we want a hybrid KEM, or a= re fine with a pure PQ KEM. Then we need to
decide if we want to attempt= to maintain the current quality where the p2p
handshake transcript is i= ndistinguishable from random. If yes, then that forces
another series of= decisions re how to construct/compose an oblivious KEM from
available p= rimitives.

At a glance, the route of classical-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 t= he layer of Kemeleon.

If we want a nice combined protocol, then we s= hould investigate the OEINC
route. It's more data to send as part of= the initial handshake, but we still
keep ElligatorSwift 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 b= ite the bullet and also
roll out a full blown PQ authentication protocol= along side everything.

One thing worth flagging for any of the byte= -0 designs (where PQ material is
sent in the clear on the very first fli= ght, like the hybrid and OEINC sketches
above): ML-KEM-768 makes the res= ponder do real work before it can decide if a
connection is even legit. = Today, the responder only needs the first 64 bytes
of an ElligatorSwift = share before it can derive the shared secret. With
ML-KEM-768, the respo= nder has to read and validate a 1184 byte encapsulation
key before runni= ng Encaps, and FIPS 203 mandates input checks on every Encaps
and Decaps= . In a permissionless P2P network, that's a meaningful change in
inb= ound DoS surface, and probably calls for stricter handshake byte limits,tighter timeouts, and possibly some form of stateless cookie/puzzle if
= handshake floods become a real problem. The classical-then-pq-upgrade path<= br>sidesteps most of this since the PQ material only shows up after the v2<= br>channel is up.

With all that said, after the above design decisio= ns are addressed, there
aren't too many concrete blockers here w.r.t= rolling this out. Of course the
development (eg: selecting/creating a l= ibrary for ML-KEM and maybe
ML-Kemeleon), and upgrade will take some tim= e. But unlike the consensus
layer, p2p encryption doesn't require th= e 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 sort= of PQ warm up before the bigger soft fork is
tackled.=C2=A0


= -- Laolu

[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 ign= ores Isogeny based crypto, and also SWOOSH [5] as it requires 200 KB pubkey= s
[5]:=C2=A0https://eprint.iacr.org/202= 3/271
[6]:=C2=A0https://eprint.iacr.o= rg/2018/024
[7]:=C2=A0https://eprin= t.iacr.org/2020/1364
[8]:=C2=A0http= s://eprint.iacr.org/2024/1086
[9]:=C2=A0https://www.youtube.com/watch?v=3DCvFCYUq5rGg<= /a>
[10]:=C2=A0https://csrc.nist.gov/csrc/media/Presentations/2025/kemeleon/images-= media/kemeleon.pdf
[11]:=C2=A0https://en.wikipedia.org/wiki/Harv= est_now,_decrypt_later

--=C2=A0You 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=C2=A0<= /span>bitcoindev+...@googlegroups.com.
To view t= his discussion visit=C2=A0http= s://groups.google.com/d/msgid/bitcoindev/CAO3Pvs9U3prZJiDs0Ns7LSA07R8hM-GQo= u_FcTZZz-JUQpUYHw%40mail.gmail.com.
<= /blockquote>

--=C2=A0
You received this messag= e because you are subscribed to the Google Groups "Bitcoin Development= Mailing List" group.
To unsubscribe from this group and stop recei= ving emails from it, send an email to=C2=A0bitcoindev= +...@googlegroups.com.
To view this discussion visit=C2=A0https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs8= i%3DpLP30nRh_iyjSRJXne19wNezmQmo%3DJAk8%2BE4uJPhg%40mail.gmail.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 bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/547ADFCA= -2BB1-4E16-A26A-C92262EBBD84%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/bitcoind= ev/d4b87b2c-63c2-488b-9e76-4e3dbeedb0c2n%40googlegroups.com.
------=_Part_377343_1524399383.1787809958526-- ------=_Part_377342_936685418.1787809958526--