Thanks for this work!
Speaking for myself (not for my co-authors), this feels like friendly, complementary work to draft-ounsworth-cfrg-kem-combiners; X-Wing could be viewed as a profile of ounsworth-kem-combiners that optimizes around the security properties of ML-KEM. Bas makes a good point that ounsworth-kem-combiners is not by itself implementable because it does not provide concrete instantiations. 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: <mailto:bas=40cloudflare....@dmarc.ietf.org> @Bas Westerbaan, <mailto:durumcrustu...@gmail.com> @Deirdre Connolly, Peter, would you be open to merging X-Wing into the generic combiner draft, or is there value in it being standalone? --- Mike Ounsworth From: CFRG <cfrg-boun...@irtf.org> On Behalf Of Bas Westerbaan Sent: Wednesday, January 10, 2024 2:14 PM To: IRTF CFRG <c...@irtf.org>; <tls@ietf.org> <tls@ietf.org> Cc: k...@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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
