From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 23 Sep 2026 19:43:32 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x9ZQl-0005R1-Rr for bitcoindev@gnusha.org; Wed, 23 Sep 2026 19:43:32 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-4519ef1babesf1506460fac.2 for ; Wed, 23 Sep 2026 19:43:27 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1790217801; cv=pass; d=google.com; s=arc-20260327; b=P16aOXwyrahwpF5vRLVMqQXwlgdoxW9uHXt/6VAnpAxsbw4LQEL2BLK6pcIgivIQnH 3/iC1w2Xod3SC9jrJH6G2gOeYkk3yFHd8f9egMsQFjg943jjNJLeVMO1eEvj35pW3m77 G5Zq6SaT/kZ7ikc5XGJsWmrQyKMI3whz2v9ZqmHLiuK0/QcIgesQmOLKZuY5PYwLTRQO 1NESfmRsjGhEdtmVjyCmXzZjtEl7/e0AzRK3KiI6phF1MQz2ulb+bLawNI7HCFeycdwS s5bzGEMZp9QAYYp+MqlaToHtIfPEIaAvw7v8CQmqSu3j++NmGFI6IYcqnkm9nVfAPWAC nEkQ== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=as67vWB5w/e6+m6iOBdhPt5Wy2mUgr+L/3ITR2p5/tQ=; fh=B4Cqpe55rIUeqUvzHxDxJNLHSeipMlZEQyxsUjG47Xs=; b=qdfo9ravnarlPxIhfRTOMvSePgpIPkMixxow7eUHQmje8kaN/APn5bZzArzkji+bHs 9hbIGylio6wFVAP0H9cIhi9eTB4RBJrCWc8zC9DY4Hyjz2bjB1cKjqQrkJVmF6nIyZVc ODnR3nMp5wWT4OCU556V4Jvow1H2PleCAvaqSkv9L7E7oUxnu4faPUHbUTbcUb58KMbX IgQVDS4L1d34jK19MQZQSf2ClWSYZRFf+IF3yLRv/xGyEnr5ElpHe5y3eCBt588TrHae W5a27ucclW82hFQggQ3Wma9RCR0cHIZ48FxciF3Zeibfc3zYK/8+z7fen+4HoqwBaDuK T+gw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=HQgtMxSW; arc=pass (i=1); spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:41::11 as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1790217801; x=1790822601; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=as67vWB5w/e6+m6iOBdhPt5Wy2mUgr+L/3ITR2p5/tQ=; b=Sl0LEED53NRObSrHXxAQAuz8rJEr9zuWmM/mu1vTMX9QkGdJoYBHGB6btWTMEnVuRF UdJoSgkaOP38J/8Tvz9cl1CVBZTOgq7ncl6fMwYXDN+4ZEp1bBc+nlZXaZCmCvSdWtl6 1D8YiKwnc3tHZFJecyDpetzzh9Zrzwc3xZ6+LyEoaw8GRuAjC/CKhrcdPeum667ezWEf bX4+5QdaKaNBm0PngtsZOSVn5a1zwgecAsMA+VxdHntStv3YgT7gj3Lhj2Hnhr2J9YQj 0FT58LIBmUiz0NiwL8eXjH2lrHeojRj68vzusx9Qksl3Cp7G2+kkQip/Q9M2g2c8aX8q oGVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790217801; x=1790822601; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to:content-type; bh=as67vWB5w/e6+m6iOBdhPt5Wy2mUgr+L/3ITR2p5/tQ=; b=Idby27/IvBAtjCDExMsWTJdqL3vk3T7YKajOQuQn1XpdIgULmSiGdy3Tv7NeI/DajD UEW8LtwJPth7LUfn6uelhpgYD22PFEg7nQ5rXKWA5a0CVy4kzOIP/0TiAVQdDWbQOGTa TbRUyJPERSf10bYUk5UgxtNy57XgZr3AWOuMiQf/aFS5aECN0tqRs3iIH6/wWDhM0L7S KK8nl2xXin1VLdY5zcitcwEglbtMRucU8ki1AkO6PlbX0tBNVwn1M3iWUXQFod88uroN jtZK+9x1+hX7VcCImgbrcCnSPvJjjxs0PuA1LkNxEDjTV0Mt/Mpo+nVF00SBhN1+hgpU /edg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790217801; x=1790822601; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=as67vWB5w/e6+m6iOBdhPt5Wy2mUgr+L/3ITR2p5/tQ=; b=roaePBj56qXPdLskn+4LnmyLZjjpMWG8yltXqDVV5RlqeUPgrTFDYacb/xlcrh/vZx sdeYNqLJo2qfRE4od+35sHVfmERkNbJdIXPWnHfXSVheSuy6bDNrkJiuqwCONoWR+O9U ed0Qw4Vneh/ofMh3yQCNQOQGA1VPDfNmQP0Q5AiG5IXn435B0TwUBom6EJ0Acgc8Dt+u wzTdo2Zn+CAqlNU2dj59zSBOqfRYnoZhgg8ROW5CCDC5Txf04p3hNepi2qI8WEjwXn2G RRRKHBvtrmtSCaQa+d55l8f8NgzIWyyXf9NCGUHG0c27Cbf3ecQoI57+l03dd1mG9Ur3 yhoA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AKwUvBwARZea/c139xvJMQ/Julp/TCrz4kNciWr+CVIzjI6ZqzZmLFAwFl7yxuMLJNt+rrbShsaZ5PuxNpPV@gnusha.org X-Gm-Message-State: AFuF++nAU1x9Ubrtqk/nlYNSXhbytMsZtgmSpoDhV7d00yv+ngt9fcZJ cynNyZiRA/r8tltGLybWTjY5yayM2kd4THuB/KdvSWA6+sF0QHe4Aqjp X-Received: by 2002:a05:6870:15cc:b0:48f:e0f6:c465 with SMTP id 586e51a60fabf-491eba6b59fmr1128575fac.51.1790217800917; Wed, 23 Sep 2026 19:43:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdcQz7jWUilZSwzIfCrtYQd129v/mRgALDDmV3jNwRNgUg==" Received: by 2002:a05:6871:384a:b0:48e:2047:1c00 with SMTP id 586e51a60fabf-48e204788f8ls4000164fac.1.-pod-prod-06-us; Wed, 23 Sep 2026 19:43:14 -0700 (PDT) X-Received: by 2002:a05:6808:6d90:b0:4cb:ae51:5971 with SMTP id 5614622812f47-4d72ac460a9mr1269898b6e.32.1790217794357; Wed, 23 Sep 2026 19:43:14 -0700 (PDT) Received: by 2002:a05:690c:e157:10b0:8a6:990a:8ca5 with SMTP id 00721157ae682-8a6990a8d66ms7b3; Wed, 23 Sep 2026 18:46:42 -0700 (PDT) X-Received: by 2002:a05:6102:5129:b0:7a7:198a:c2be with SMTP id ada2fe7eead31-7af1eaeab2emr623814137.28.1790214401668; Wed, 23 Sep 2026 18:46:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1790214401; cv=pass; d=google.com; s=arc-20260327; b=QXoAZqhJU/LwVRqFxJ3j7xAwihNdyvI7fjzZK3llJ0Le/gz/o27Q3zKS4kkrRpqBcQ 9eZ0RAA6EiIxkumysze5RSAO/rBcnILNuItJ4OD7u4LBR+pIT7DEnoapyzMc+b6PKVwp owO2fvRAy0KQLh7SuujPnIiSweYX5wrnraKDB4C9+nMeg5WqRDoGZzlV9TxGWdKfbihg xQAY8plLdsW/dFJ0VVHtsedeEUpSCyjD9wSHxhx+H1FBfQgxhLswCjqyNOcwsXE94xBb Dt6810XoltChgQQhdCfHx0NEhiq79hHGlVBrgL3XLwCoL1IL+Cq3nLt1Uwr52tDni1MO 3ouA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=gKkMU/nUQiUHQdW+Z1Tl118zqT0JZM3g0N1sfv+GAs4=; fh=6oqMfeOBVuYjnlm7zD4gDBa+cN0LRBSZCElN4e5EUEc=; b=RAy3s7Ex8FnO0j4/aYUuIMkBdbwaqHX55V/SgCw2drvlQ5O+a8FP9aR494ihY6+kVF CDRYH0qZnvV6tMz1IAnHyZM8ubK+VZpEz+MYlS/dOXABfbmQC4faa4dylazoouzWNN+F UuZmEGOQI3J1XmZvLLQGns/Sixfgdk6jefg64UduxuEziaPQFPFJZIkA8o9HMdCOWgzR EuCwU6XWtoNTKUWxhoW8n96EAlwISOy4yQyDXg7bpYe/ERi3Xmtzu4FLT46o7fajkYHR hbEZdkJeBFtEo23xJGttcfN554HJUrNhgH+jVc1tGFs78NEcK+2w5eJ0bg0grqNbTWvr 0IOQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=HQgtMxSW; arc=pass (i=1); spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:41::11 as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yx2-x11.google.com (mail-yx2-x11.google.com. [2607:f8b0:4864:41::11]) by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-9852b37105bsi8234241.2.2026.09.23.18.46.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 18:46:41 -0700 (PDT) Received-SPF: pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:41::11 as permitted sender) client-ip=2607:f8b0:4864:41::11; Received: by mail-yx2-x11.google.com with SMTP id 956f58d0204a3-66e4ab20f4bso1839131d50.0 for ; Wed, 23 Sep 2026 18:46:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1790214401; cv=none; d=google.com; s=arc-20260327; b=GScgqLNsVoIOEnbhH8w1YyCjxWkwHA49JFflIDauvHVyihcDS+XfbgoK0wudfSvF8z P8q2BwnChFnQTPV4oHC71+ehzK6XssBviQviTbRsis1R4irz3PzOA/up3vMsxfUv1ne3 fkXFm2/l1QWMvBh0x6ha/vlHF9LYLBKYaT8eqa7vSr7koFKeiAjKV0p4dzdfy4KbPNhA fFpc9cdH0/f1rht7ZIFQiiVSbhtD+7wKEBZxtlybEr9qaZslw/fNIPllF5aheR4WlnJt W3yw+arvwGEKDxREd50ORTGSh3pzX0p7LpSjwzgv9kSusz3B8suIeATqVLEk5QfTVeBH Lx5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=gKkMU/nUQiUHQdW+Z1Tl118zqT0JZM3g0N1sfv+GAs4=; fh=6oqMfeOBVuYjnlm7zD4gDBa+cN0LRBSZCElN4e5EUEc=; b=DLZR8rsXJdvG09eO9uN9tFmKZ41TBg9WhKSsqCSkeqZOkY5G0+aERF39719r9c0IJi XZ/j+SW13HxH8/KJ6pPGv6UeDZ0DR3KdIJaTgxNzifUKcg+LfbzjcbNwAZq6Ob3dk13Q NK8O9sTRHzmya6zIJPREOl9ngCbPwttQFsoDP/wSHPXyutqFvbUg1peit/MOEM0ph0gH 7vewTfoMdOSDWXhGzDSAijPZ6MJUddmr891iRd/D4AD5rVs95vuFVch/uhhJXpk3h/hS cmtdm7TxDhJM/UFlDaqqt4RhC3b1tHKUPJSLNpBTCGo4PcZg2yhpaYZv/TGZe9kQavaU J9oA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AYBFou1MiAK3TlDEN0TbfM8iwPrLhEz/l4gXB+niCM/jp6l7LZd0m4gnNHrZttyrZFc XsUW2BeH/Ip8liVUmbXkTYObbzzsoeEZT/MULbhQ2gdzoJ5WLQ37mFWdBVt8K6L26yqqTSG1SXt yd/tgR5/9G8++MnvP1vzo6C9r9V+Ppy/hXKmb6ShyZAoYpgqt/7vtS2/Tf76ajnCCocaNgZ0WSt 4UR0CeNYFzptKALP4Ae4BilxRWjJhpoKsgkKgmCeOSlnJdvdITMLwd5Zpw8CksfHAESV98J/BZQ 4Gb8iN4Y00DfFQ8n3jZwgGDTfBEhBBJrIob/g5BLgDHHarFQ2mQMn0ZFXAy3d3PbRoSYlwmQ6uQ kjfaCyCTn2tCL/9UN4G/Lm5/UwDyHFK3v8AJEzuNxK4V7lUaGxkNpSgSUvY3YO0VPmUlfr3r2tm UOepoHXZIyCnkW X-Received: by 2002:a05:690e:1685:b0:66f:c1bc:408a with SMTP id 956f58d0204a3-672ed3e7bb5mr637669d50.77.1790214400905; Wed, 23 Sep 2026 18:46:40 -0700 (PDT) MIME-Version: 1.0 References: <547ADFCA-2BB1-4E16-A26A-C92262EBBD84@gmail.com> In-Reply-To: From: Olaoluwa Osuntokun Date: Wed, 23 Sep 2026 18:46:29 -0700 X-Gm-Features: AcwNN1XHcEJnV-rNH38futeytZCacCVDR54JEb9z5lYLDbLMkLYKLH5G7aylEOI Message-ID: Subject: Re: [bitcoindev] A Post-Quantum Path for BIP 324 To: Liam Gilligan Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000007016aa065c30c592" X-Original-Sender: laolu32@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=HQgtMxSW; arc=pass (i=1); spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:41::11 as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --0000000000007016aa065c30c592 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Liam, > Does a CRQC meaningfully lower the cost of fingerprinting or censorship? > It is hard to imagine a world where running Shor's is cheaper than timing > analysis, so it is safe to say that the pseudorandom bytestream still > achieves its goal of raising fingerprinting costs, even in light of a > CRQC. Is it? Ignoring the fact that without a constant bit rate connection, Bitcoin is a giant clock on the wire, any sort of timing analysis or attack= s would be stochastic in nature vs the ability to deterministic break ECDH an= d co i the future. > Ignoring CRQCs briefly, the only way node operators can detect a MitM to > begin with is by communicating their session IDs on an authenticated > channel (otherwise it is still susceptible to a MitM), and thus must be > done out of band. Yep, to prevent this the addr message would need to include a long-term-ish public key along with a signature over a requisite message digest to enable bootstrapping. Private uses cases would still communicate pairing information out of band however (eg: light client on your phone that connects to your full node over the public internet). > Now, let's talk forward secrecy. As mentioned in [3], the rekey mechanism > itself could be secure against a CRQC, but in any case, because > confidentiality against passive attacks is violated, it hardly matters. Can you expand on that? Perhaps you're confusing forwards vs backwards secrecy? Forward secrecy is achieved in the face of a CRQC if the connection doesn't rely solely on a long term static key, in that each session may use a long term key for authentication, but fresh ephemeral keys are derived for each session. Backwards secrecy (a.k.a future or post compromise security) is achieved if the session continually injects new fresh randomness to frequently negotiat= e new fresh keys for encryption within the session. So if someone your encryption key was leaked, if the transcript continues, you'll eventually derive a fresh new key not linked to the prior leak. > 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 > Sybiling? Totally. If it's a semi-deterministic process that just requires offline computation vs active network attacks, I'd consider that cheaper myself. I make no claims at all re the time horizon, but if we look backwards, my laptop can easily break asymmetric cryptography that may have been considered secure in the 90s. Agreed re the importance of private transaction broadcast, though that is a distinct concern imo as that need not use the Bitcoin p2p network at all (eg: payment to peer over LN that include a bitcoin txn to broadcast in the onion payload, or ephemeral Tor connections for broadcast). > As far as the pseudorandom bytestream, observability of active attacks, > and forward secrecy go, I do genuinely think there is not much to be > empirically gained by introducing PQ-P2P. > I agree with previous discussion that CTU is the appropriate upgrade path= , > for the following reasons: Dope, it certainly is nice in that it would result in a smaller surface are= a shift for existing implementations. The missing gap is a new agile-enough negotiation system. Yeah I don't think the extra overhaul required for OSH is worth it, other than being able to roll out some cool modern cartographic techniques. Eithe= r way as you note, in order to tick all the boxes, authentication is required= . Arguably the lack of authentication is a defect in BIP-324 itself as many years have passed since the initial sketches to atck on this feature with n= o actual code deployed. -- Laolu On Thu, Aug 27, 2026 at 8:38=E2=80=AFAM Liam Gilligan wrote: > 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, an= d > 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 little > 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) > performing a PQ key exchange over the classically encrypted channel. > - OSH (one-shot hybrid): This is option 2 as laid out by Laolu. > Basically concatenating the PQ KEM keys/ciphertext to the ECDH keys. A= s > previously discussed, this can be done with various encodings (such as > Kemeleon and/or an OEINC) to preserve the pseudorandom bytestream 324 > currently guarantees. > - PQ-P2P (post-quantum peer-to-peer) > - CRQC (cryptographically relevant quantum computer) > - HNDL (harvest now, decrypt later): Recording classically encrypted > traffic with the intention of decrypting it with a CRQC later. > > What problem does PQ-P2P solve? > > In other words, what features/improvements introduced by BIP-324 are > negated by a CRQC? Well, the properties BIP-324 seeks to achieve are as > follows[1]: > > - *Confidentiality against passive attacks*: A passive attacker having > recorded a v2 P2P bytestream (without timing and fragmentation informa= tion) > must not be able to determine the plaintext being exchanged by the nod= es. > - *Observability of active attacks*: A session ID identifying the > encrypted channel uniquely is derived deterministically from a > Diffie-Hellman negotiation. An active man-in-the-middle attacker is fo= rced > to incur a risk of being detected as peer operators can compare sessio= n IDs > manually, or using optional authentication methods possibly introduced= in > future protocol versions. > - *Pseudorandom bytestream*: A passive attacker having recorded a v2 > P2P bytestream (without timing information and fragmentation informati= on) > must not be able to distinguish it from a uniformly random bytestream. > - *Shapable bytestream*: It should be possible to shape the bytestream > to increase resistance to traffic analysis (for example, to conceal bl= ock > propagation), or censorship avoidance[2]. > - *Forward secrecy*: An eavesdropping attacker who compromises a > peer's sessions secrets should not be able to decrypt past session tra= ffic, > except for the latest few packets. > - *Upgradability*: The proposal provides an upgrade path using > transport versioning which can be used to add features like authentica= tion, > PQC handshake upgrade, etc. in the future. > - *Compatibility*: v2 clients will allow inbound v1 connections to > minimize risk of network partitions. > - *Low overhead*: the introduction of a new P2P transport protocol > should not substantially increase computational cost or bandwidth for = nodes > that implement it, compared to the current protocol. > > The shapable bytestream, upgradability, compatibility, and low overhead > properties are intrinsic to the design and are not affected by the > existence of a CRQC. However, the other four properties are violated: > > *Confidentiality against passive attacks*: A CRQC can break ECDH, and > therefore can passively determine the plaintext exchanged. > > *Observability of active attacks*: An active attacker armed with a CRQC > can relay both nodes' ElligatorSwift encodings unmodified, causing both t= o > derive the same session ID. It can then recover either node's ephemeral > private key from the recorded encoding and compute that same shared secre= t, > allowing it to read and modify traffic while both operators see matching > session IDs. > > *Pseudorandom bytestream*: This follows from confidentiality against > passive attacks being violated.[3] > > *Forward secrecy*: This follows from confidentiality against 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 > quantum attacker can distinguish a recorded v2 P2P bytestream from a > uniformly random bytestream. However, the reason BIP-324 seeks to create = a > pseudorandom bytestream is to raise the cost of fingerprinting and > censorship[4], and it admits that methods such as timing or port analysis > can fingerprint node traffic. Does a CRQC meaningfully lower the cost of > fingerprinting or censorship? It is hard to imagine a world where running > Shor's is cheaper than timing analysis, so it is safe to say that the > pseudorandom bytestream still achieves its goal of raising fingerprinting > costs, even in light of a CRQC. > > Next, consider the observability of active attacks. Ignoring CRQCs > briefly, the only way node operators can detect a MitM to begin with is b= y > communicating their session IDs on an authenticated channel (otherwise it > is still susceptible to a MitM), and thus must be done out of band. > Basically, BIP-324 enables MitM detection but provides no means of doing > so. AFAIK, no one compares session IDs out of band, and in any case the > proportion of nodes that do so is near zero. This failure is more so a > reason to introduce some 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 mechanism > 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 > sensitive information in the stream is the origin of transactions[6]. Now= , > we'll approach this in a way similar to how we approached the pseudorando= m > bytestream. 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] attack. Can we imagine a world in which running Shor's i= s > cheaper than simply MitMing? Can we even imagine a world in which Shor's = is > cheaper than Sybiling? This seems like an argument for simply using priva= te > broadcast[8]. > > That last point does not take into account a HNDL attack. HNDL attacks ar= e > presently far cheaper than any active attacks, as an attacker need only > record traffic. Importantly, it means the origin of all future transactio= ns > broadcast through v2 can be determined, and it is likely that such an > attack is currently taking place. Private broadcast does defeat a HNDL > attack on 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 other= s. > 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 sendrawtransaction, and does nothing for the > confidentiality of other traffic. Broken encryption can only be fixed wit= h > 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 > empirically gained by introducing PQ-P2P. > > However, the argument that cheaper active attacks against confidentiality > exist is an argument for authentication, not an argument against PQ-P2P. > Confidentiality can be defeated both by breaking the encryption and by > bypassing it entirely (via MitM or Sybil attacks), and the solution is to > fix both. 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 path= , > 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 fo= r > every outgoing connection before knowing whether the peer supports PQ = at > all. CTU only does so after negotiation. > 2. Pseudorandom bytestream: CTU preserves the property at zero cost, > because the PQ material is already inside the encrypted channel. OSH m= ust > additionally implement Kemeleon, and arguably an OEINC combiner, purel= y to > avoid regressing it. > 3. Extension rather than replacement: CTU extends BIP-324, whereas OSH > replaces it and would 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 > logical 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 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] > https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#cite_note-= shapable_hs_tor_circumvention_4 > > [3] Forward secrecy is currently achieved by deterministically generating > new keys every 224 messages. This does not protect future messages, but > means an attacker with access to intermediary keys (i.e., not the shared > secret derived from ECDH or the key it produces) cannot derive previous > keys and decrypt past messages. Given an intermediary key, it is not > immediately clear to me how an attacker could use a CRQC to find a previo= us > key, but it hardly matters: if they recorded past messages they wish to > decrypt, then they likely also recorded the handshake, and can break the > initial ECDH from there and can therefore decrypt all traffic. However, > assuming an attacker armed with a CRQC discovers an intermediary key but > has not recorded the handshake, then I suppose forward secrecy would be > preserved. > > [4] "A pseudorandom bytestream excludes identification techniques based o= n > pattern matching, and makes it easier to shape the bytestream in order to > mimic other protocols used on the Internet. This raises the cost of a > connection censoring firewall, forcing them to either resort to a full Mi= tM > attack, or operate on a more obvious allowlist basis, rather than a > blocklist basis." -- BIP-324 Motivation, > https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#motivation > > [5] See sipa's post on Countersign and other private authentication > protocols: https://wuille.net/posts/private-authentication-protocols/ > > [6] Relay timing, block and filter requests, and addr gossip are all part > 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 > significant caveats around qubit counts and hardware architecture; see th= e > 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. >> Guess I should learn to read better :P >> >> regards, >> conduition >> On Friday, May 8th, 2026 at 8:21 PM, conduition >> wrote: >> >> Hi all, >> >> 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 >> did want to chime in on this statement: >> >> 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, whose security is predicated on using "noise" = to >> hide a secret value. For these cryptosystems, usually a type of "hint" i= s >> 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. >> >> >> It's important to emphasize this only considers the NIST-standardized >> KEMs. If we zoom out to the broader ecosystem of PQ PKE candidates, ther= e >> are several options for non-interactive key exchange systems that'd be a >> drop-in replacement for ECDH. >> >> For instance, oriented isogeny-based systems like CSIDH [1] [2] permit >> this kind of construction. Both parties publish a short (64 to 128 byte) >> pubkey 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 otherwi= se >> 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 exchange can take a good few dozen milliseconds. >> >> In general, any post-quantum-secure commutative 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 BIP324 as yet, I'm not sure how crucial this >> non-interactivity property is to the protocol. If it's not a big deal, t= hen >> I'd gladly toss my hat in for lattices and a hybridized ML-KEM >> construction, given so much of the internet is already migrating to this= . >> It makes sense to follow standards if we can. Going full-TLS would proba= bly >> be overkill IMO - It is designed for a very different (centralized) PKI >> architecture and would buy us a ticket for a train we probably don't wan= t >> to ride. >> >> Maybe there's a more applicable standard, 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 t= hat >> is reusable for other use-cases beyond Bitcoin. >> >> Also, if we go with a hybrid scheme, we should have clear migration path= s >> 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 CRQCs turn out = to >> 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, >> mostly 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 look random,... the inner PQ handshake is just more >> ciphertext. A future QC adversary doing harvest-now-decrypt-later would >> break the outer ECDH eventually, but I think they'd then still have to >> break ML-KEM-768 to get the v3 transport keys, which is kind of the whol= e >> point. So we'd probably get hybrid security against the QC threat and al= so >> keep the property that today's wire bytes are indistinguishable from ran= dom. >> >> That said, I'm not sure how far we should really take the >> pseudorandomness argument,... traffic shape (packet sizes, timings, >> query/response 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 opt= ion >> 1, since the responder still commits after 64 bytes and not after a >> 1184-byte ML-KEM key,... though I haven't thought hard about wether ther= e >> are other DoS vectors the inner upgrade introduces. >> >> 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), TL= S >> has it's own fingerprint, which would probably undo the >> censorship-resistance angle. And it bundles authentication with encrypti= on, >> which we explicitly decoupled. >> >> One thing worth looking at: OpenSSH (whose chacha20-poly1305 constructio= n >> we drew from originally) shipped mlkem768x25519-sha256 as default in 10.= 0 >> last year, and they just concatenate-and-hash the two shared secrets. Th= eir >> 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 >> reference for ours. >> >> /jonas >> >> On May 6, 2026, at 12:15=E2=80=AFPM, Olaoluwa Osuntokun wrote: >> >> Hi Ethan, >> >> That's a great question. >> >> 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 >> dependencies slim. Many years ago there was a concerted push to remove >> openssl >> as a dependency from the project. So I would imagine the idea of rolling >> 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 >> suites. >> >> If ensuring that BIP 324 continues to implement an oblivious KEM is a ke= y >> requirement, then TLS 1.3 doesn't fit the bill. >> >> Regarding a hybrid PQ KEM, there exists an IETF to add a new key agreeme= nt >> suite to TLS 1.3: >> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/. >> Only secp256+384(r1) and x25519 are supported as elliptic curves in this >> draft. >> >> One additional aspect is that today BIP 324 doesn't implement >> authentication at >> all, you only get confidentiality. TLS 1.3 would mean introducing >> certificates >> in some fashion, thereby coupling 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 general 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%20proto= col%3F >> . >> >> >> -- Laolu >> >> >> >> On Tue, May 5, 2026 at 2:18=E2=80=AFPM Ethan Heilman = wrote: >> >>> 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 >>> 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= ? >>> Is the case against solely to not have TLS 1.3 as a complex dependency = in >>> bitcoin-core? >>> >>> The advantages of TLS 1.3: >>> >>> 1. Make Bitcoin P2P connections blend in with all the other TLS >>> connections. This isn't strong privacy, you can distinguish TLS encrypt= ed >>> Bitcoin traffic via timing and size, but it reduces accidents where a >>> firewall sees an unknown protocol and blocks it. >>> >>> 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. >>> >>> >>> On Tue, May 5, 2026, 00:41 Olaoluwa Osuntokun wrote: >>> >>>> Hi y'all, >>>> >>>> In case you weren't already tired of all the recent dev list chatter r= e >>>> post >>>> quantum cryptography, here's another! >>>> >>>> When the topic of Bitcoin transitioning to a post quantum world is >>>> brought up, >>>> the discussion typically focuses on the consensus layer re swapping ou= t >>>> vulnerable signature schemes. However, the consensus layer isn't the >>>> only area >>>> of Bitcoin that relies in cryptography that would be broken in the fac= e >>>> of a >>>> powerful quantum computer! That's right, I'm talking about BIP 324, th= e >>>> peer to >>>> peer encryption BIP for Bitcoin. >>>> >>>> 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, which i= s >>>> then >>>> used to encrypt all traffic between 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, permitting it to decrypt all traffic. It's actually >>>> 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 is >>>> commonly >>>> referred to as the: "harvest, decrypt later" (HNDL) strategy [11]. >>>> >>>> Compared to a consensus change, which requires widespread market >>>> agreement, and >>>> coordination to achieve, upgrading BIP 324 to be post quantum resistan= t >>>> 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 stumbled 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 discussion on the various design tradeoffs that 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 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 >>>> on the >>>> tin, ML-KEM is a lattice based Key-Encapsulation Mechanism. The phrase >>>> KEM >>>> might sound unfamiliar with those comfortable with ECDH, but ECDH is >>>> 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 >>>> 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 >>>> elegant >>>> one at that: >>>> * KeyGen() -> {k, k*G} >>>> * Normal EC key generation. >>>> >>>> * Encaps(pub) -> {capsule =3D x*G, secret =3D pub*x} >>>> * The core ECDH routine. The ephemeral public key is actually th= e >>>> "capsule". The resulting secret is the ECDH output with the >>>> 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 >>>> 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], there is >>>> no known non-interactive key exchange protocol like we enjoy today wit= h >>>> 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 secre= t >>>> 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-interactive >>>> setting >>>> (no messages sent), this doesn't map cleanly. >>>> >>>> As a result, ML-KEM looks more like a hybrid encryption protocol (Alic= e >>>> 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? >>>> >>>> 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 encryption. A hybrid KEM is attractive as an >>>> encryption >>>> channel derived from such a KEM is secure if _any_ of the combined >>>> schemes are >>>> secure. This permits schemes to hedge a bit, as hey, maybe the PQ stuf= f >>>> 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. >>>> >>>> The initial handshake would look something like: >>>> * Alice -> Bob: alice_encaps || initiator_garbage >>>> * 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 over to Alice. He can also encrypt the first message at >>>> this >>>> point. >>>> >>>> * Alice -> Bob: initiator_garbage_terminator || first_encrypted_packe= t >>>> * Alice de-encapsulates the shared secret, and can now also start t= o >>>> 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 tha= t >>>> point: >>>> * `sha256_tagged("bip324_ml_kem", ml_kem_secret, alice_encaps, >>>> ml_kem_capsule)` >>>> >>>> ### 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: ellswift_alice || alice_encaps || initiator_garbage >>>> * Bob -> Alice: ellswift_bob || ml_kem_capsule || responder_garbage |= | >>>> responder_garbage_terminator || first_encrypted_packet >>>> * Alice -> Bob: initiator_garbage_terminator || first_encrypted_packe= t >>>> >>>> Then following guidelines of [7], we'd then replace `v2_ecdh` with >>>> something >>>> like `v3_hybrid_shared_secret`: >>>> * `sha256_tagged("bip324_ellswift_xonly_ecdh_mlkem_768", ml_kem_ss, >>>> 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 tha= t >>>> both >>>> the pure PQ and hybrid versions renders the ElligatorSwift usage prett= y >>>> much >>>> useless. ElligatorSwift encodes a 32-byte public key as a 64-byte valu= e >>>> 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-KE= M >>>> encapsulation key is sent in plaintext over the wire. An ML-KEM key ha= s >>>> identifiable structure, as it's a giant vector of polynomial >>>> 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 >>>> public >>>> key, then encodes it as one giant integer, utilizing rejection samplin= g. >>>> 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 smaller, while the ciphertexts map to a larger value. >>>> Another >>>> tradeoff is that the Kemeleon key generation is ~3x slower than normal >>>> ML-KEM >>>> generation. >>>> >>>> One thing to note here is that Kemeleon's "looks random" property isn'= t >>>> quite >>>> on the same footing as ElligatorSwift's. ElligatorSwift is statistical= ly >>>> indistinguishable from random, since every 512-bit string is a valid >>>> encoding. >>>> Kemeleon's indistinguishability 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 >>>> 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 >>>> 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 ElligatorSwift handshake, but >>>> use ML-KEM >>>> within that initial encrypted transport to upgrade to a PQ shared >>>> secret. >>>> >>>> 2. Use the Outer Encrypts Inner Nested Combiner (OEINC - "OINK") >>>> 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 >>>> BIP 324 >>>> v2 would be mostly unchanged, then we _upgrade_ to BIP 324 v3 within v= 2. >>>> >>>> >>>> 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 th= e >>>> channel >>>> isn't PQC protected 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 use 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 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 key= s >>>> to PQ >>>> hybrid 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 >>>> 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]) >>>> describes an >>>> OEINC scheme where the outer KEM >>>> encrypts the inner KEM, wherein the KEM ciphertext of an inner KEM is >>>> encrypted >>>> using a shared secret derived from the outer KEM. The two KEM >>>> ciphertexts and >>>> the two derived keys are then used alongside a hybrid combiner 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 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 >>>> outKEM.Encap(kem_pubkey_outer) >>>> * (encrypt_key_1, encrypt_key_2) =3D KDF(shared_secret_outer) >>>> * (shared_secret_inner, capsule_inner) =3D >>>> 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, >>>> 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, >>>> 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, >>>> capsule_inner) >>>> * combined_shared_secret =3D combine(encrypt_key_2, >>>> 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 >>>> issue with >>>> this though is that though ciphertext uniformity (the encapsulated >>>> 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 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 likely, >>>> given >>>> size limits) to include a signed OKEM key. However then that would >>>> introduce >>>> authentication into the combined set, which explicitly wasn't a design >>>> goal >>>> of BIP 324. >>>> >>>> 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 an >>>> asymmetric >>>> protocol within 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. >>>> >>>> ----- >>>> >>>> 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. Then w= e >>>> need to >>>> decide if we want to attempt to maintain the current quality where the >>>> p2p >>>> handshake transcript is indistinguishable from random. If yes, then >>>> that forces >>>> another series of decisions re how to construct/compose an oblivious >>>> KEM from >>>> available primitives. >>>> >>>> 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 a= re >>>> 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 >>>> 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 bite 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 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 ElligatorSwift share before it can derive the shared secret. Wit= h >>>> ML-KEM-768, the responder has to read and validate a 1184 byte >>>> encapsulation >>>> key before running Encaps, and FIPS 203 mandates input checks on every >>>> Encaps >>>> and Decaps. In a permissionless P2P network, that's a meaningful chang= e >>>> in >>>> inbound 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 >>>> sidesteps most of this since the PQ material only shows up after the v= 2 >>>> channel is up. >>>> >>>> With all that said, after the above design decisions are addressed, >>>> 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 maybe >>>> ML-Kemeleon), and upgrade will take some time. But unlike the consensu= s >>>> layer, p2p encryption doesn't require the 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. >>>> >>>> >>>> -- 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] >>>> 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/Presentations/2025/kemeleon/images-me= dia/kemeleon.pdf >>>> [11]: https://en.wikipedia.org/wiki/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+...@googlegroups.com. >>>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs9U3prZJiDs0Ns7LSA0= 7R8hM-GQou_FcTZZz-JUQpUYHw%40mail.gmail.com >>>> . >>>> >>> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs8i%3DpLP30nRh_iyjSRJ= Xne19wNezmQmo%3DJAk8%2BE4uJPhg%40mail.gmail.com >> . >> >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/547ADFCA-2BB1-4E16-A26A-C92= 262EBBD84%40gmail.com >> . >> >> >> >> -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/d4b87b2c-63c2-488b-9e76-4e3d= beedb0c2n%40googlegroups.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/= CAO3Pvs_%2Borjc1mbEVSpOpCApy1SjuGH%2ByhRfJX2aGB6ZZ0hAyg%40mail.gmail.com. --0000000000007016aa065c30c592 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Liam,

> Does a CRQC meaningfully lower = the cost of fingerprinting or censorship?
> It is hard to imagine a w= orld where running Shor's is cheaper than timing
> analysis, so i= t is safe to say that the pseudorandom bytestream still
> achieves it= s goal of raising fingerprinting costs, even in light of a
> CRQC.
Is it? Ignoring the fact that without a constant bit rate connection,<= br>Bitcoin is a giant clock on the wire, any sort of timing analysis or att= acks
would be stochastic in nature vs the ability to deterministic break= ECDH and
co i the future.


> Ignoring CRQCs briefly, the o= nly way node operators can detect a MitM to
> begin with is by commun= icating their session IDs on an authenticated
> channel (otherwise it= is still susceptible to a MitM), and thus must be
> done out of band= .

Yep, to prevent this the addr message would need to include a long= -term-ish
public key along with a signature over a requisite message dig= est to enable
bootstrapping. Private uses cases would still communicate = pairing
information out of band however (eg: light client on your phone = that
connects to your full node over the public internet).

> N= ow, 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 matte= rs.

Can you expand on that? Perhaps you're confusing forwards vs= backwards
secrecy?

Forward secrecy is achieved in the face of a= CRQC if the connection doesn't
rely solely on a long term static ke= y, in that each session may use a long
term key for authentication, but = fresh ephemeral keys are derived for each
session.

Backwards secr= ecy (a.k.a future or post compromise security) is achieved if
the sessio= n continually injects new fresh randomness to frequently negotiate
new f= resh keys for encryption within the session. So if someone your
encrypti= on key was leaked, if the transcript continues, you'll eventually
de= rive a fresh new key not linked to the prior leak.

> Can we imagi= ne a world in which running Shor's is cheaper than simply
> MitMi= ng? Can we even imagine a world in which Shor's is cheaper than
>= Sybiling?

Totally. If it's a semi-deterministic process that ju= st requires offline
computation vs active network attacks, I'd consi= der that cheaper myself. I
make no claims at all re the time horizon, bu= t if we look backwards, my
laptop can easily break asymmetric cryptograp= hy that may have been
considered secure in the 90s.

Agreed re the= importance of private transaction broadcast, though that is a
distinct = concern imo as that need not use the Bitcoin p2p network at all
(eg: pay= ment to peer over LN that include a bitcoin txn to broadcast in the
onio= n payload, or ephemeral Tor connections for broadcast).

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


> I agree with prev= ious discussion that CTU is the appropriate upgrade path,
> for the f= ollowing reasons:

Dope, it certainly is nice in that it would result= in a smaller surface area
shift for existing implementations. The missi= ng gap is a new agile-enough
negotiation system.

Yeah I don't= think the extra overhaul required for OSH is worth it, other
than being= able to roll out some cool modern cartographic techniques. Either
way a= s you note, in order to tick all the boxes, authentication is required.
= Arguably the lack of authentication is a defect in BIP-324 itself as manyyears have passed since the initial sketches to atck on this feature with= no
actual code deployed.


-- Laolu


On Thu, Aug 27, 2026 at 8:38=E2=80=AFAM Liam Gilligan <liamdgilligan@gmail.com> wrote:<= br>

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 l= ittle 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 = should not be able to decrypt past session traffic, except for the latest f= ew packets.
  • Upgradability: The proposal provides a= n upgrade path using transport versioning which can be used to add features= like authentication, PQC handshake upgrade, etc. in the future.
  • Compatibility: v2 clients will allow inbound v1 connections = to minimize risk of network partitions.
  • Low overhead: the introduction of a new P2P transport protocol should not substantial= ly increase computational cost or bandwidth for nodes that implement it, co= mpared 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 unmodifie= d, causing both to derive the same session ID. It can then recover either n= ode's ephemeral private key from the recorded encoding and compute that= same shared secret, allowing it to read and modify traffic while both oper= ators see 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 defe= ated 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= than timing analysis, so it is safe to say that the pseudorandom bytestrea= m still achieves its goal of raising fingerprinting costs, even in light of= a CRQC.

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 mech= anism itself could be secure against a CRQC, but in any case, beca= use 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&= #39;ll approach this in a way similar to how we approached the pseudorandom= bytestream. ECDH acts to raise the cost of a passive attack on confidentia= lity (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]= attack. 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 Sybiling? This seems like an argument for simply using private broadc= ast[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 sendrawtransaction, and does nothing for the confidentiality of o= ther traffic. Broken encryption can only be fixed with working encryption.<= /p>

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= 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] 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= identification techniques based on pattern matching, and makes it easier t= o shape the bytestream in order to mimic other protocols used on the Intern= et. This raises the cost of a connection censoring firewall, forcing them t= o either resort to a full MitM attack, or operate on a more obvious allowli= st basis, rather than a blocklist basis." -- BIP-324 Motivation, https://github.com/bitcoi= n/bips/blob/master/bip-0324.mediawiki#motivation

[5] See sipa'= ;s post on Countersign and other private authentication protocols: https://wuille.net/posts/private-authentic= ation-protocols/

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

[7] https://en.wikipedia.org/wiki/Sybil_att= ack

[8] https://github.com/bitcoin/bit= coin/pull/29415

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


<= br>
On Sat= urday, May 9, 2026 at 9:39:13=E2=80=AFAM UTC conduition wrote:
Oopsie, I just saw Laolu's footnote #4 a= bout ignoring isogeny crypto. Guess I should learn to read better :P
<= div style=3D"font-family:Arial,sans-serif;font-size:14px">
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 CSIDH with be= tter implementations=C2=A0[4] but still key exchange can take a good few do= zen milliseconds.=C2=A0

In general, any post-quantum-secure commutative = 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 BIP324 as yet= , I'm not sure how crucial this non-interactivity property is to the pr= otocol. If it's not a big deal, then I'd gladly toss my hat in for = lattices and a hybridized ML-KEM construction, given so much of the interne= t is already migrating to this. It makes sense to follow standards if we ca= n. Going full-TLS would probably be overkill IMO - It is designed for a ver= y 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 implementation reference, see [5]. Otherwi= se 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 Bitcoin.

Also, if we go with a hy= brid scheme, we should have clear migration paths to transition to either p= ure PQC (if a CRQC appears and breaks ECDH, we might as well discard it), o= r back to classical ECDH (if CRQCs turn out to be impossible).

=
regards,
conduition

=



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 <la= o...@gmail.com> wrote:

<= div>Hi Ethan,=C2=A0

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

First, I don't speak for Bitcoin Core by any means= (btcd has also implemented
BIP 324 FWIW). Based on past observed behavi= or, they typically prefer to keep
dependencies slim. Many years ago ther= e was a concerted push to remove openssl
as a dependency from the projec= t. So I would imagine the idea of rolling out
full blown TLS 1.3 might e= ncounter some resistance.

In terms of cryptography, BIP 324 as defin= ed uses secp256k1. TLS 1.3 as
specified doesn't support secp256k1 wi= thin the set of supported cipher suites.

If ensuring that BIP 324 co= ntinues 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 a= n IETF to add a new key agreement
suite to TLS 1.3:=C2=A0https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/.<= br>Only secp256+384(r1) and x25519 are supported as elliptic curves in this= draft.

One additional aspect is that today BIP 324 doesn't impl= ement authentication at
all, you only get confidentiality. TLS 1.3 would= mean introducing certificates
in some fashion, thereby coupling concern= s 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 general purpo= se 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%20proto= col%3F.


-- Laolu



= On Tue, May 5, 2026 at 2:18=E2=80=AFPM Ethan Heilman <eth...@gmail.com> wrote:
Th= anks Laolu for thinking through making PQ BIP 324 and writing this up.
<= br>Reading through what you wrote made me what wonder, 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 the case against solely t= o not have TLS 1.3 as a complex dependency in bitcoin-core?

The advantages of TLS 1.3:

1. Make Bitcoin P2P connections blend in w= ith all the other TLS connections. This isn't strong privacy, you can d= istinguish TLS encrypted Bitcoin traffic via timing and size, but it reduce= s accidents where a firewall sees an unknown protocol and blocks it.
<= div dir=3D"auto">
2. Use of QUIC for faster rela= y, 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.


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

In case you we= ren't already tired of all the recent dev list chatter re post
quant= um cryptography, here's another!

When the topic of Bitcoin trans= itioning to a post quantum world is brought up,
the discussion typically= focuses on the consensus layer re swapping out
vulnerable signature sch= emes. However, the consensus layer isn't the only area
of Bitcoin th= at relies in cryptography that would be broken in the face of a
powerful= quantum computer! That's right, I'm talking about BIP 324, the pee= r to
peer encryption BIP for Bitcoin.

Like everything else on the= Internet today, BIP 324 uses ECDH to allow two
connecting peers to deri= ve a shared secret known only to them, which is then
used to encrypt all= traffic between them. As ECDH relies on Elliptic Curve
cryptography, a = future quantum computer would be able to eavesdrop on a p2p
handshake tr= anscript, then derive the underlying private keys to the ephemeral
ECDH = public key, permitting it to decrypt all traffic. It's actually worse t= han
that, as today adversaries can collect all encrypted p2p Bitcoin tra= ffic, with
the hope of being able to decrypt it all at a future date. Th= is is commonly
referred to as the: "harvest, decrypt later" (H= NDL) strategy [11].

Compared to a consensus change, which requires w= idespread market agreement, and
coordination to achieve, upgrading BIP 3= 24 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 stumbled ont= o 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 discussion o= n the various design tradeoffs that came up as I was
researching this p2= p encryption transition.

## PQ BIP 324 Design Questions

1. Do= we want to pursue a hybrid KEM (key encapsulation mechanism), or go with=C2=A0 =C2=A0a pure PQ KEM?

2. Is it still a key requirement that = the initial handshake be
=C2=A0 =C2=A0indistinguishable from a random by= te string?

=C2=A0 =C2=A02a. If yes to the above, then should we go w= ith classical-then-pq-upgrade,
=C2=A0 =C2=A0or a one shot hybrid oblivio= us KEM.


## A Brief Intro to KEMs + ML-KEM

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

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

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

=C2=A0=C2=A0* D= ecaps(priv, capsule) -> secret
=C2=A0 =C2=A0 =C2=A0* 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 tha= t:
=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 core ECDH routin= e. The ephemeral public key is actually the
=C2=A0 =C2=A0 =C2=A0 =C2=A0<= span>=C2=A0"capsule". The resulting secret is the ECDH out= put with the remote
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0party&= #39;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 exchange using th= e ephemeral public key
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0and= 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]= , 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, whose security is predicated on using "no= ise" to hide a secret value.
For these cryptosystems, usually a typ= e of "hint" is sent to make everything
work out nicely like in= ECDH. However, in the stricter non-interactive setting
(no messages sen= t), this doesn't map cleanly.

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

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

This brings us to our first design question....

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

A hy= brid KEM would keep the existing ECDH, _also_ do ML-KEM, then securely
c= ombine (there's some subtlety there, see [6][7]) the resulting in a
= final secret value for encryption. A hybrid KEM is attractive as an encrypt= ion
channel derived from such a KEM is secure if _any_ of the combined s= chemes are
secure. This permits schemes to hedge a bit, as hey, maybe th= e PQ stuff is
actually broken in the future but ECDH isn't. If it= 9;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. In= stead, 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 -&= gt; Bob: alice_encaps || initiator_garbage
=C2=A0 =C2=A0=C2=A0* Alice derives an encapsulation key, and sends it to Bob.

=C2=A0= * Bob -> Alice: ml_kem_capsule || responder_garbage || responder_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 message at this=
=C2=A0 =C2=A0 =C2=A0point.

=C2=A0* Alice -> Bob: initiator_ga= rbage_terminator || first_encrypted_packet
=C2=A0 =C2=A0* Alice de-encap= sulates the shared secret, and can now also start to encrypt
=C2=A0 =C2= =A0 =C2=A0messages.

We'd then replace `v2_ecdh` with something l= ike a `v3_mlkem` that derives the
final shared secret based on the sent/= received transcript up until that point:
=C2=A0=C2=A0* `sha= 256_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:

=C2=A0* Alice -> Bob: ellswif= t_alice || alice_encaps || initiator_garbage
=C2=A0* Bob -> Alice: el= lswift_bob || ml_kem_capsule || responder_garbage || responder_garbage_term= inator || first_encrypted_packet
=C2=A0* 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_sh= ared_secret`:
=C2=A0=C2=A0* `sha256_tagged("bip324_ell= swift_xonly_ecdh_mlkem_768", ml_kem_ss, ecdh_point_x32, alice_encaps, = ml_kem_capsule, ellswift_alice, ellswift_bob)`

## PQ/Hybrid Obfuscat= ed KEMs

At this point, those that are familiar with BIP 324 will rec= ognize that both
the pure PQ and hybrid versions renders the ElligatorSw= ift usage pretty much
useless. ElligatorSwift encodes a 32-byte public k= ey as a 64-byte value which
is indistinguishable from a uniformly distri= buted bitstream. In a bubble, this
means that the initial BIP 324 handsh= ake 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 plai= ntext over the wire. An ML-KEM key has
identifiable structure, as it'= ;s a giant vector of polynomial coefficients mod
3329, which is easily r= ecognizable over the wire.

Luckily, there's an ML-KEM analogue t= o ElligatorSwift, called Kemeleon
[8][9][10]! In a similar fashion to El= ligatorSwift, it takes an ML-KEM public
key, then encodes it as one gian= t integer, utilizing rejection sampling.
Kemeleon applies this mapping b= oth to the encapsulation keys, and also the
capsule ciphertext that encr= ypts the shared secrets. The ML-KEM keys end up
being a bit smaller, whi= le the ciphertexts map to a larger value. Another
tradeoff is that the K= emeleon key generation is ~3x slower than normal ML-KEM
generation.
<= br>One thing to note here is that Kemeleon's "looks random" p= roperty isn't quite
on the same footing as ElligatorSwift's. Ell= igatorSwift is statistically
indistinguishable from random, since every = 512-bit string is a valid encoding.
Kemeleon's indistinguishability = is computational, resting on a Module-LWE
style assumption. So if you na= ively concatenate an ElligatorSwift key and a
Kemeleon key, the pair is = only as obfuscated as the weakest visible half. This
asymmetry is what m= otivates the OEINC construction discussed below.

This brings us to o= ur second design question....

Do we still want to ensure that the BI= P-324 handshake looks identical to a
pseudorandom bytestream from the ve= ry first message?

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

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

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

### Classical Encrypted Channel = Upgrades to PQ

With the first option, we simply use one KEM right af= ter the other. So BIP 324
v2 would be mostly unchanged, then we _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 h= andshake
=C2=A0=C2=A0* Phase 1: negotiation of PQ KEM schem= e over the encrypted handshake
=C2=A0 =C2=A0 =C2=A0* Can be optional, if= we just pick a set PQ KEM scheme.
=C2=A0 =C2=A0 =C2=A0* Before this poi= nt, 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* Pha= se 2: do normal ML-KEM within the ElligatorSwift derived encrypted
=C2= =A0 =C2=A0=C2=A0transport
=C2=A0 =C2=A0 =C2=A01. Alice send= s the encapsulation key
=C2=A0 =C2=A0 =C2=A02. Bob derives a secrets, en= crypts it using the 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 sketched 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 transpor= t keys

The upside of this option is that the outer part of BIP 324 r= emains unchanged,
then with another round trip, we're able to upgrad= e the encryption keys to PQ
hybrid security. The downside is that the ve= ry first messages sent aren't PQ
from the start, but a PQ adversary = wouldn't be able to decrypt the actual
Bitcoin p2p messages (as we w= ait to send those until the upgrade). The
handshake still looks like jus= t random bytes.

### Outer Encrypts Inner Nested Combiner

For = the second option, [8] (with talk video [9] and slides [10]) describes anOEINC scheme where the outer KEM
encrypts the inner KEM, wherein the K= EM ciphertext of an inner KEM is encrypted
using a shared secret derived= from the outer KEM. The two KEM ciphertexts and
the two derived keys ar= e then used alongside a hybrid combiner to derive a
final shared secret.= =C2=A0

Unlike the classical-then-pq-upgrade that establ= ishes a classical channel, then
uses that to upgrade to pq channel, OEIN= C 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 t= he very first handshake I sketched out.

A sketch of this KEM looks s= omething like:
=C2=A0=C2=A0* Setup:
=C2=A0 =C2=A0= =C2=A0* The outer KEM is BIP 324's ElligatorSwift-encoded secp25= 6k1 DHKEM.
=C2=A0 =C2=A0 =C2=A0 =C2=A0* It serves as the outer KEM becau= se its on-wire encoding is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statistical= ly 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_outer) =3D = outKEM.Gen()
=C2=A0 =C2=A0=C2=A0* (kem_secret_inner, kem_pu= bkey_inner) =3D inKEM.Gen()
=C2=A0 =C2=A0=C2=A0* combined_p= ubkey =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(kem_pu= bkey_outer)
=C2=A0 =C2=A0=C2=A0* (encrypt_key_1, encrypt_ke= y_2) =3D KDF(shared_secret_outer)
=C2=A0 =C2=A0=C2=A0* (sha= red_secret_inner, capsule_inner) =3D inKEM.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 || encrypted_capsule_inner
=C2=A0 =C2=A0=C2=A0<= /span>* combined_shared_secret =3D combine(encrypt_key_2, shared_secret_inn= er, combined_capsule)

=C2=A0=C2=A0* Decaps(combined_sec= ret, 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_secret_outer, capsule= _outer)
=C2=A0 =C2=A0=C2=A0* (encrypt_key_1, encrypt_key_2)= =3D KDF(shared_secret_outer)
=C2=A0 =C2=A0=C2=A0* capsule_= inner =3D decrypt(encrypt_key_1, encrypted_capsule_inner)
=C2=A0 =C2=A0<= span>=C2=A0* shared_secret_inner =3D inKEM.Decaps(kem_secret_inner, = capsule_inner)
=C2=A0 =C2=A0=C2=A0* combined_shared_secret = =3D combine(encrypt_key_2, shared_secret_inner, combined_capsule)

This is done over just sending the two encapsulated secrets plainly as I<= br>outlined above in order to achieve a stronger security notion. The issue= with
this though is that though ciphertext uniformity (the encapsulated= secrets) is
achieved, the two public keys sent are randomly looking, bu= t not in a uniform
manner. In practice, this might not really matter muc= h AFAICT (a theoretical
adversary would be able to distinguish the Ellig= ator half from the Kemeleon
half).

### Drivel: PQ-Obfuscated Auth= entication

The biggest issue with Drivel as a fit for BIP 324 is tha= t 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 exch= anged, 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 likely, = given
size limits) to include a signed OKEM key. However then that would= introduce
authentication into the combined set, which explicitly wasn&#= 39;t a design goal
of BIP 324.

With that caveat in mind, here'= ;s the construction itself. Drivel [8] combines
the OEINC scheme with an= other 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 = published by the server to then encrypt a fresh new ephemeral
KEM.
-----=C2=A0

So there we have it. Before drafting a co= ncrete v3 transport, we need to
decide if we want a hybrid KEM, or are f= ine 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 indis= tinguishable from random. If yes, then that forces
another series of dec= isions re how to construct/compose an oblivious KEM from
available primi= tives.

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. Th= e ML-KEM keys are
encrypted, so there's no need to sprinkle in the l= ayer of Kemeleon.

If we want a nice combined protocol, then we shoul= d 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 adv= ersary gaining a
distinguisher for Kemeleon, then maybe we need to bite = the bullet and also
roll out a full blown PQ authentication protocol alo= ng side everything.

One thing worth flagging for any of the byte-0 d= esigns (where PQ material is
sent in the clear on the very first flight,= like the hybrid and OEINC sketches
above): ML-KEM-768 makes the respond= er do real work before it can decide if a
connection is even legit. Toda= y, the responder only needs the first 64 bytes
of an ElligatorSwift shar= e before it can derive the shared secret. With
ML-KEM-768, the responder= has to read and validate a 1184 byte encapsulation
key before running E= ncaps, 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 byte limits,
tig= hter timeouts, and possibly some form of stateless cookie/puzzle if
hand= shake floods become a real problem. The classical-then-pq-upgrade path
s= idesteps most of this since the PQ material only shows up after the v2
c= hannel is up.

With all that said, after the above design decisions a= re addressed, there
aren't too many concrete blockers here w.r.t rol= ling this out. Of course the
development (eg: selecting/creating a libra= ry for ML-KEM and maybe
ML-Kemeleon), and upgrade will take some time. B= ut unlike the consensus
layer, p2p encryption doesn't require the wi= despread market agreement that an
actual soft fork does. BIP 324 is a mu= ch 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


-- L= aolu

[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 statem= ent 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://eprin= t.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/kemeleon/images-media/kemeleon.pdf
[11]:=C2=A0https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later

--=C2=A0
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 f= rom it, send an email to=C2=A0bitcoindev+...@googlegroups.com= .
To view this discussion visit=C2=A0https://groups.google.com/d/msgid/= bitcoindev/CAO3Pvs9U3prZJiDs0Ns7LSA07R8hM-GQou_FcTZZz-JUQpUYHw%40mail.gmail= .com.

--=C2= =A0
You received this message because you are subscribed to the Google Grou= ps "Bitcoin Development Mailing List" group.
To unsubscribe from this gr= oup and stop receiving emails from it, send an email to=C2=A0<= /span>bitcoindev+...@= googlegroups.com.To view this di= scussion visit=C2=A0https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs8i%3DpL= P30nRh_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 ht= tps://groups.google.com/d/msgid/bitcoindev/547ADFCA-2BB1-4E16-A26A-C92262EB= BD84%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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/d4b87b2c-63c2-488b-9e76-4e3dbeedb0c2n%40googlegrou= ps.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/CAO3Pvs_%2Borjc1mbEVSpOpCApy1SjuGH%2ByhRfJX2aGB6ZZ0hAyg%= 40mail.gmail.com.
--0000000000007016aa065c30c592--