]> SandboxAQ

durumcrustulum@gmail.com

MPI-SP & Radboud University

peter@cryptojedi.org

Cloudflare

bas@cloudflare.com

IRTF Crypto Forum post quantum kem PQ/T hybrid This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML-KEM-768. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Crypto Forum Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction

Warning: ML-KEM-768 has not been standardised X-Wing uses ML-KEM-768, which has not been standardised yet. Thus X-Wing is not finished, yet, and should not be used, yet.

Motivation There are many choices that can be made when specifying a hybrid KEM: the constituent KEMs; their security levels; the combiner; and the hash within, to name but a few. Having too many similar options are a burden to the ecosystem. The aim of X-Wing is to provide a concrete, simple choice for post-quantum hybrid KEM, that should be suitable for the vast majority of use cases.

Design goals By making concrete choices, we can simplify and improve many aspects of X-Wing.

• Simplicity of definition. Because all shared secrets and cipher texts are fixed length, we do not need to encode the length. Using SHA3-256, we do not need HMAC-based construction. For the concrete choice of ML-KEM-768, we do not need to mix in its ciphertext, see .
• Security analysis. Because ML-KEM-768 already assumes QROM, we do not need to complicate the analysis of X-Wing by considering stronger models.
• Performance. Not having to mix in the ML-KEM-768 ciphertext is a nice performance benefit. Furthermore, by using SHA3-256 in the combiner, which matches the hashing in ML-KEM-768, this hash can be computed in one go on platforms where two-way Keccak is available.

We aim for "128 bits" security (NIST PQC level 1). Although at the moment there is no peer-reviewed evidence that ML-KEM-512 does not reach this level, we would like to hedge against future cryptanalytic improvements, and feel ML-KEM-768 provides a comfortable margin. We aim for X-Wing to be usable for most applications, including specifically HPKE .

Not an interactive key-agreement Traditionally most protocols use a Diffie-Hellman (DH) style non-interactive key-agreement. In many cases, a DH key agreement can be replaced by the interactive key-agreement afforded by a KEM without change in the protocol flow. One notable example is TLS . However, not all uses of DH can be replaced in a straight-forward manner by a plain KEM.

Not an authenticated KEM In particular, X-Wing is not, borrowing the language of , an authenticated KEM.

Comparisons

With HPKE X25519Kyber768Draft00 X-Wing is most similar to HPKE's X25519Kyber768Draft00 . The key differences are:

• X-Wing uses the final version of ML-KEM-768.
• X-Wing hashes the shared secrets, to be usable outside of HPKE.
• X-Wing has a simpler combiner by flattening DHKEM(X25519) into the final hash.
• X-Wing does not hash in the ML-KEM-768 ciphertext.

There is also a different KEM called X25519Kyber768Draft00 which is used in TLS. This one should not be used outside of TLS, as it assumes the presence of the TLS transcript to ensure non malleability.

With generic combiner The generic combiner of can be instantiated with ML-KEM-768 and DHKEM(X25519). That achieves similar security, but:

• X-Wing is more performant, not hashing in the ML-KEM-768 ciphertext, and flattening the DHKEM construction, with the same level of security.
• X-Wing has a fixed 32 byte shared secret, instead of a variable shared secret.
• X-Wing does not accept the optional counter and fixedInfo arguments.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Conventions and Definitions This document is consistent with all terminology defined in . The following terms are used throughout this document to describe the operations, roles, and behaviors of HPKE:

• concat(x0, ..., xN): returns the concatenation of byte strings. concat(0x01, 0x0203, 0x040506) = 0x010203040506.
• random(n): return a pseudorandom byte string of length n bytes produced by a cryptographically-secure random number generator.

Cryptographic Dependencies X-Wing relies on the following primitives:

• ML-KEM-768 post-quantum key-encapsulation mechanism (KEM) :
  • ML-KEM-768.KeyGen(): Randomized algorithm to generate an ML-KEM-768 key pair (pk_M, sk_M) of an encapsulation key pk_M and decapsulation key sk_M. Note that ML-KEM-768.KeyGen() returns the keys in reverse order of GenerateKeyPair() defined below.
  • ML-KEM-768.Encaps(pk_M): Randomized algorithm to generate (ss_M, ct_M), an ephemeral 32 byte shared key ss_M, and a fixed-length encapsulation (ciphertext) of that key ct_M for encapsulation key pk_M.
  • ML-KEM-768.Decap(ct_M, sk_M): Deterministic algorithm using the decapsulation key sk_M to recover the shared key from ct_M.
  To generate deterministic test vectors, we also use
  • ML-KEM-768.KeyGenDerand(seed): Same as ML-KEM-768.KeyGen(), but derandomized as follows. seed is 64 bytes. seed[0:32] is used for z (line 1 algorithm 15), and seed[32:64] is used for d (line 1 algorithm 12).
  • ML-KEM-768.EncapsDerand(pk_M, seed): Same as ML-KEM-768.Encaps() but derandomized as follows. seed is 32 bytes and used for m (line 1 algorithm 16).
• X25519 elliptic curve Diffie-Hellman key-exchange defined in :
  • X25519(k,u): takes 32 byte strings k and u representing a Curve25519 scalar and curvepoint respectively, and returns the 32 byte string representing their scalar multiplication.
  • X25519_BASE: the 32 byte string representing the standard base point of Curve25519. In hex it is given by 09000000000000000000000000000000000000000000.

Note that 9 is the standard basepoint for X25519, cf .

• Symmetric cryptography.
  • SHAKE128(message, outlen): The extendable-output function (XOF) defined in Section 6.2 of .
  • SHA3-256(message): The hash defined in defined in Section 6.1 of .

X-Wing Construction

Encoding and sizes X-Wing encapsulation key, decapsulation key, ciphertexts and shared secrets are all fixed length byte strings.

Decapsulation key (private):

2432 bytes

Encapsulation key (public):

1216 bytes

Ciphertext:

1120 bytes

Shared secret:

32 bytes

Key generation An X-Wing keypair (decapsulation key, encapsulation key) is generated as follows. GenerateKeyPair() returns the 2432 byte secret encapsulation key sk and the 1216 byte decapsulation key pk.

Key derivation For testing, it is convenient to have a deterministic version of key generation. An X-Wing implementation MAY provide the following derandomized variant of key generation. seed must be 96 bytes. GenerateKeyPairDerand() returns the 2432 byte secret encapsulation key sk and the 1216 byte decapsulation key pk.

Combiner Given 32 byte strings ss_M, ss_X, ct_X, pk_X, representing the ML-KEM-768 shared secret, X25519 shared secret, X25519 ciphertext (ephemeral public key) and X25519 public key respectively, the 32 byte combined shared secret is given by: where XWingLabel is the following 6 byte ASCII string

Encapsulation Given an X-Wing encapsulation key pk, encapsulation proceeds as follows. pk is a 1216 byte X-Wing encapsulation key resulting from GeneratePublicKey() Encapsulate() returns the 32 byte shared secret ss and the 1120 byte ciphertext ct.

Derandomized For testing, it is convenient to have a deterministic version of encapsulation. An X-Wing implementation MAY provide the following derandomized function. pk is a 1216 byte X-Wing encapsulation key resulting from GeneratePublicKey() seed MUST be 64 bytes. EncapsulateDerand() returns the 32 byte shared secret ss and the 1120 byte ciphertext ct.

Decapsulation ct is the 1120 byte ciphertext resulting from Encapsulate() sk is a 2432 byte X-Wing decapsulation key resulting from GenerateKeyPair() pk is a 1216 byte X-Wing encapsulation key resulting from GenerateKeyPair() Decapsulate() returns the 32 byte shared secret.

Use in HPKE X-Wing satisfies the HPKE KEM interface as follows. The SerializePublicKey, DeserializePublicKey, SerializePrivateKey and DeserializePrivateKey are the identity functions, as X-Wing keys are fixed-length byte strings, see . DeriveKeyPair() is given by where the HPKE private key and public key are the X-Wing decapsulation key and encapsulation key respectively. The argument ikm to DeriveKeyPair() SHOULD be at least 32 octets in length. (This is contrary to which stipulates it should be at least Nsk=2432 octets in length.) Encap() is Encapsulate() from . Decap() is Decapsulate() from . X-Wing is not an authenticated KEM: it does not support AuthEncap() and AuthDecap(), see . Nsecret, Nenc, Npk, and Nsk are defined in .

Use in TLS 1.3 For the client's share, the key_exchange value contains the X-Wing encapsulation key. For the server's share, the key_exchange value contains the X-Wing ciphertext.

Security Considerations Informally, X-Wing is secure if SHA3 is secure, and either X25519 is secure, or ML-KEM-768 is secure. More precisely, if SHA3-256, SHA3-512, SHAKE-128, and SHAKE-256 may be modelled as a random oracle, then the IND-CCA security of X-Wing is bounded by the IND-CCA security of ML-KEM-768, and the gap-CDH security of Curve25519, see . The security of X-Wing relies crucially on the specifics of the Fujisaki-Okamoto transformation used in ML-KEM-768. In particular, the X-Wing combiner cannot be assumed to be secure, when used with different KEMs.

IANA Considerations This document requests/registers a new entry to the "HPKE KEM Identifiers" registry.

Value:

TBD (please)

KEM:

X-Wing

Nsecret:

32

Nenc:

1120

Npk:

1216

Nsk:

2432

Auth:

no

Reference:

This document

Furthermore, this document requests/registers a new entry to the TLS Named Group (or Supported Group) registry, according to the procedures in .

Value:

TBD (please)

Description:

X-Wing

DTLS-OK:

Y

Recommended:

Y

Reference:

This document

Comment:

PQ/T hybrid of X25519 and ML-KEM-768

TODO

• Which validation do we want to require?

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References UK National Cyber Security Centre One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. Entrust Limited Proton AG BSI The migration to post-quantum cryptography often calls for performing multiple key encapsulations in parallel and then combining their outputs to derive a single shared secret. This document defines a comprehensible and easy to implement Keccak- based KEM combiner to join an arbitrary number of key shares, that is compatible with NIST SP 800-56Cr2 [SP800-56C] when viewed as a key derivation function. The combiners defined here are practical split- key PRFs and are CCA-secure as long as at least one of the ingredient KEMs is. n.d. n.d. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. University of Waterloo Cisco Systems University of Haifa and Amazon Web Services Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-stebila-tls-hybrid- design. Cloudflare Cloudflare This memo defines X25519Kyber768Draft00, a hybrid post-quantum KEM, for HPKE (RFC9180). This KEM does not support the authenticated modes of HPKE. Cloudflare University of Waterloo This memo defines X25519Kyber768Draft00, a hybrid post-quantum key exchange for TLS 1.3. Venafi sn3rd This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the recommended column of the selected TLS registries. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. n.d.

Test vectors # TODO: replace with test vectors that re-use ML-KEM, X25519 values

Acknowledgments TODO acknowledge.