Re: [TLS] [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
Bas Westerbaan <bas@cloudflare.com> Thu, 11 January 2024 15:38 UTC
Return-Path: <bas@cloudflare.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C815EC469B24 for <tls@ietfa.amsl.com>; Thu, 11 Jan 2024 07:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK_Dj_FH4GQv for <tls@ietfa.amsl.com>; Thu, 11 Jan 2024 07:38:50 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DBDC06F228 for <tls@ietf.org>; Thu, 11 Jan 2024 07:26:54 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-558b5f4cf2dso216264a12.2 for <tls@ietf.org>; Thu, 11 Jan 2024 07:26:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1704986812; x=1705591612; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DmksdkGWuWB9jD4hcB1pRDxdwVfA5vaq0rd+CzSuSC0=; b=VNP2t6/RLqLXZ9xLzx+3non7ODENgzqv9tm3pXb7jkjV1zSviCEOMWI7+OtFcGk/sk SBpFwNfEYEcgnUi712PpoN+uok9h2LrAMI3ttBjSIj6bKqm0eZDmOd5Av4i1nd8risGd dRzoXJAANCFjQp8ExIkiu/LpIN8XmozzWpmCOVbJXbNBt4npL/ANAtPvQW3nUKtxI+W9 SJ8OhJRPNBYAwcCG4BXyezTVVQAV8M7+Sy8mzE5bMilMkoBXmY8bvgd6Y8Wh10wMLIk6 z9cfz9JNspQI8FOaqHHnwd48aSsDML9lsroPxoFbvcLImWoMYo597Ja+FfOVZb0FrzvH 4lMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704986812; x=1705591612; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DmksdkGWuWB9jD4hcB1pRDxdwVfA5vaq0rd+CzSuSC0=; b=LVL5ghVZNB4CiAGEkf0bZkwcoqLOmC1k2ATCuIqwM61rB5dpezB00LCkRS/vohgKNM Ku/9tNHSVoSGzyfge0eZX+qJvZw3+TLc6HGW0Fuob4jFZ2sgyXJTVnwDxu0QvejkQew6 0G5VU4aOptVzXMBwS7IVgZJzNw9W4knTORXD4Wl7+mu7UCPmrqXA1o0see/ez3xgx0tO JrHTFiJwxCgL+CgSYdC542WgwMtfD/g+rWEYzzFkYeTuGl7/vAL/c83jXMjbNpFdjFLW Ve1AggmWGUkNU9lPxT1Ros6eyNYQv9ocHpzlqS0BPuITRq1H7NpRFHWq5ttq9A5/mSPo tFlw==
X-Gm-Message-State: AOJu0YzSMraxG8nDBU+KW5udf6zTuqWNHnRssF/4G1XfrbYuSCLysI1l LdoOVDaDiTopAgwUbbl0Zv+jTYTu0B7ieOMniPVjJN5EQ2uX8qMgDL0SHIlc4qm+YvTf
X-Google-Smtp-Source: AGHT+IHjqYmENA4HYBAj0pwdyDfYunYtpFWrFQTf6u9njomy/gBIQgBIw/OLeIEfYz06X4v2EYvpSyPmJbGGBEhySDw=
X-Received: by 2002:a50:9f4a:0:b0:553:6de7:3158 with SMTP id b68-20020a509f4a000000b005536de73158mr653811edf.81.1704986812055; Thu, 11 Jan 2024 07:26:52 -0800 (PST)
MIME-Version: 1.0
References: <CAMjbhoWZxsLFH6yBc0hdx3t3SohurXGkfMzouoxGXM92HBR_dw@mail.gmail.com> <CH0PR11MB5739F6307E16B3B6A01BFBFA9F692@CH0PR11MB5739.namprd11.prod.outlook.com> <CAMjbhoWysgatzqy1uR+4qx1mVHW8wbn6KvPuD5z79w_6+bueRw@mail.gmail.com> <CH0PR11MB57392AC372810A4B2B2E9E359F682@CH0PR11MB5739.namprd11.prod.outlook.com>
In-Reply-To: <CH0PR11MB57392AC372810A4B2B2E9E359F682@CH0PR11MB5739.namprd11.prod.outlook.com>
From: Bas Westerbaan <bas@cloudflare.com>
Date: Thu, 11 Jan 2024 16:26:41 +0100
Message-ID: <CAMjbhoWBHhkHfORRWCv+mquDD8HG1eopL=JC6z00LDtWQdFeyg@mail.gmail.com>
To: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>
Cc: IRTF CFRG <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>, Deirdre Connolly <durumcrustulum@gmail.com>, "karo@cupdev.net" <karo@cupdev.net>
Content-Type: multipart/alternative; boundary="000000000000480b60060ead2d16"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VB385v1MYXRVxko9Wy0ylp8kxd0>
Subject: Re: [TLS] [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jan 2024 15:38:54 -0000
On Thu, Jan 11, 2024 at 3:56 PM Mike Ounsworth <Mike.Ounsworth= 40entrust.com@dmarc.ietf.org> wrote: > Right. I’m just thinking out loud here. > > > > If the Generic is > > > > KDF(counter || KEM1_ct || KEM1_ss || KEM2_ct || KEM2_ss || fixedInfo) > > > > And X-Wing is: > > > > SHA3-256( “\.//^\” || ML-KEM_ss || X25519_ss || X25519_ct || X25519_pk ) > > > > It looks pretty close to me; you’ve dropped the ML-KEM CT, added the > X25519 recipient public key, and moved the fixedInfo from the end to the > beginning. > > > > The question is: is that close enough to be considered a profile? Do we > want to adapt the Generic so that X-Wing is properly a profile? > The X-Wing combiner is not necessarily secure when instantiated with other primitives. The big one is that we need a ciphertext collision resistant KEM. Also we use that ML-KEM mixes in its own public key in the shared secret. And then there are more assumptions: assuming fixed length ciphertext/shared secrets, assuming we fit within the KDF block size (see Dan's e-mail). We could make the generic combiner simpler depending on the primitives used, but that will make the generic combiner specification much more complex/subtle. Binding to the ECC public keys is probably not a bad idea in general. > Certainly it would make no sense for some IETF protocols to use X-Wing > while others use the ML-KEM + X25519 instantiation of the generic. I think > I’m convincing myself that the Generic should be adjusted so that X-Wing is > the obvious instantiation for ML-KEM + X25519. > > > > Aside: do you have an opinion about fixedInfo as a prefix vs a suffix? We > chose suffix simply because it more obviously aligns with SP 800-56Cr2, and > we’ve all had the experience of FIPS labs being picky about things like > that. > > > > --- > > *Mike* Ounsworth > > > > *From:* Bas Westerbaan <bas=40cloudflare.com@dmarc.ietf.org> > *Sent:* Thursday, January 11, 2024 7:07 AM > *To:* Mike Ounsworth <Mike.Ounsworth@entrust.com> > *Cc:* IRTF CFRG <cfrg@irtf.org>; <tls@ietf.org> <tls@ietf.org>; Deirdre > Connolly <durumcrustulum@gmail.com>; karo@cupdev.net > *Subject:* Re: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM? > > > > Speaking for myself (not for my co-authors), this feels like friendly, > complementary work to draft-ounsworth-cfrg-kem-combiners; I agree. We could > consider adding a section with concrete instantiations, and the first one > would be X-Wing 😊 (followed > > > > Speaking for myself (not for my co-authors), this feels like friendly, > complementary work to draft-ounsworth-cfrg-kem-combiners; > > > > I agree. > > > > We could consider adding a section with concrete instantiations, and the > first one would be X-Wing 😊 (followed by ML-KEM + P-256, Brainpool, and > RSA variants). > > > > I guess that leads to the following question: @Bas Westerbaan > <bas=40cloudflare.com@dmarc.ietf.org>, @Deirdre Connolly > <durumcrustulum@gmail.com>, Peter, would you be open to merging X-Wing > into the generic combiner draft, or is there value in it being standalone? > > > > X-Wing explicitly trades genericity for simplicity. We will not get such a > simple and efficient construction if it is the instantiation of an > easy-to-use generic construction. > > > > Best, > > > > Bas > > > > > > --- > > *Mike* Ounsworth > > > > *From:* CFRG <cfrg-bounces@irtf.org> *On Behalf Of *Bas Westerbaan > *Sent:* Wednesday, January 10, 2024 2:14 PM > *To:* IRTF CFRG <cfrg@irtf.org>; <tls@ietf.org> <tls@ietf.org> > *Cc:* karo@cupdev.net > *Subject:* [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM? > > > > Dear tls and cfrg working groups, With ML-KEM (née Kyber) expected to be > finalized this year, it’s time to revisit the question of which PQ/T hybrid > KEMs to standardize, and which to recommend. # Status quo For TLS at the > time of writing there > > Dear tls and cfrg working groups, > > With ML-KEM (née Kyber) expected to be finalized this year, it’s time to > revisit the question of which PQ/T hybrid KEMs to standardize, and which to > recommend. > > # Status quo > > For TLS at the time of writing there are two PQ/T hybrids registered: > X25519Kyber768 [1] and P256Kyber768 [2]. The former has been deployed > widely [3]. Both are instances of the hybrid-design draft [4], which use > the simple combiner ss_ECC || ss_Kyber, which is suitable for TLS, but not > for other applications such as HPKE, as it’s not IND-CCA2 robust [5]. > > For HPKE, there is a different KEM called X25519Kyber768 [6], which uses a > different combiner that mixes in the X25519 ephemeral key, by using HPKE’s > DHKEM construction instead of raw X25519. > > There is also the ounsworth-kem-combiners I-D [7] that informed by [5] > proposes the generic combiner > > KDF( counter || ct1 || ss1 || ct2 || ss2 || fixedInfo, outputBits ) > > From a security standpoint that would be suitable for HPKE and TLS. To TLS > it is somewhat unattractive as it requires hashing the typically large PQ > ciphertexts, and adds some extra hashing in the conversion of the ECDH into > a KEM. On the other hand, for TLS it would be nice to have a KEM that is > also suitable for HPKE, as HPKE is used in ECH. > > From a usability perspective, ounsworth-kem-combiners requires the user to > make several choices: which KEMs and in particular which method to use to > turn ECDH into a KEM, which security levels, which KDF, etc. > > # The proposal: X-Wing > > Let us introduce X-Wing [0]. The goal of X-Wing is to be *the* go-to PQ/T > hybrid KEM for the majority of use cases (including TLS and HPKE): no need > to make choices, or understand the subtleties. > > X-Wing aims for 128-bit security, and for that combines the time-tested > X25519 with ML-KEM-768 [8]. X-Wing uses the combiner > > SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || > pk_X25519 ) > > Here ss_X25519 is the plain X25519 shared secret; ct_X25519 is the > ephemeral public key; xwing-label a 6-byte label. Note that it doesn’t hash > in the ML-KEM ciphertext. For a generic KEM one cannot leave out the > ciphertext, but in the case of ML-KEM we can, assuming we can model > SHA3/SHAKE as a random oracle. This is proven in [0]. The gist is that FO > transform in ML-KEM makes it “ciphertext collision resistant”: even if the > underlying lattice problem is broken, it’s infeasible to create from one > ciphertext another different ciphertext with the same shared secret. > > # Not final > > We would love to hear your input: X-Wing is not final. For one, ML-KEM > itself might still change (presumably only in minor ways) before final > standardization. We think the CFRG would be a good venue to standardize > X-Wing — do you concur? > > Best, > > Bas, Deirdre, Karolin, Manuel, Peter > > > PS. We want to mention explicitly that we see value in the kem-combiners > and hybrid-design drafts as generic safe methods to construct hybrids for > those use cases where X-Wing would not suffice. > > > [0] Spec: https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-Y-JP2DY$> > Proof: https://eprint.iacr.org/2024/039 > <https://urldefense.com/v3/__https:/eprint.iacr.org/2024/039__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-Xl0zY2C$> > [1] Full name X25519Kyber768Draft00. > https://datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-bUDJTlz$> > [2] Full name SecP256r1Kyber768Draft00. > https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-cpge9_6$> > [3] > https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html > <https://urldefense.com/v3/__https:/blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-X2cJwvg$> > https://twitter.com/bwesterb/status/1734586155868287457 > <https://urldefense.com/v3/__https:/twitter.com/bwesterb/status/1734586155868287457__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-agVitjD$> > [4] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-axrezMz$> > [5] https://link.springer.com/chapter/10.1007/978-3-319-76578-5_7 > <https://urldefense.com/v3/__https:/link.springer.com/chapter/10.1007/978-3-319-76578-5_7__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-U_tyIdl$> > [6] > https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-V-p_aAA$> > [7] https://datatracker.ietf.org/doc/draft-ounsworth-cfrg-kem-combiners/ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ounsworth-cfrg-kem-combiners/__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-bx4gLTn$> > [8] Following earlier deployment of X25519Kyber768, despite targeting 128 > bits, we use ML-KEM-768 instead of ML-KEM-512 to hedge against advances in > lattice attacks. > >
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… D. J. Bernstein
- [TLS] X-Wing: the go-to PQ/T hybrid KEM? Bas Westerbaan
- Re: [TLS] [EXTERNAL] [CFRG] X-Wing: the go-to PQ/… Mike Ounsworth
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Bas Westerbaan
- Re: [TLS] [EXTERNAL] [CFRG] X-Wing: the go-to PQ/… Bas Westerbaan
- Re: [TLS] [EXTERNAL] [CFRG] X-Wing: the go-to PQ/… Mike Ounsworth
- Re: [TLS] [EXTERNAL] Re: [CFRG] X-Wing: the go-to… Mike Ounsworth
- Re: [TLS] [EXTERNAL] Re: [CFRG] X-Wing: the go-to… Bas Westerbaan
- Re: [TLS] [EXTERNAL] [CFRG] X-Wing: the go-to PQ/… Bas Westerbaan
- Re: [TLS] [CFRG] [EXTERNAL] X-Wing: the go-to PQ/… Peter C
- Re: [TLS] [CFRG] [EXTERNAL] X-Wing: the go-to PQ/… Mike Ounsworth
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Kampanakis, Panos
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Deirdre Connolly
- Re: [TLS] X-Wing: the go-to PQ/T hybrid KEM? Filippo Valsorda
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Salz, Rich
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Sophie Schmieg
- Re: [TLS] [EXT] Re: [CFRG] X-Wing: the go-to PQ/T… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Orie Steele
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Scott Fluhrer (sfluhrer)
- Re: [TLS] X-Wing: the go-to PQ/T hybrid KEM? Martin Thomson
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… D. J. Bernstein
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… D. J. Bernstein
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… D. J. Bernstein
- Re: [TLS] X-Wing: the go-to PQ/T hybrid KEM? Watson Ladd
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Jack Grigg
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Bas Westerbaan
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Bas Westerbaan
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… D. J. Bernstein
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Ilari Liusvaara
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… D. J. Bernstein
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Eric Rescorla
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Ilari Liusvaara
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Peter Schwabe
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… D. J. Bernstein
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… D. J. Bernstein
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Peter Schwabe
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… D. J. Bernstein
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… Natanael
- Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KE… D. J. Bernstein