]> 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

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 the Quantum Random Oracle Model (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 these operations:

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

Cryptographic Dependencies X-Wing relies on the following primitives:

• ML-KEM-768 post-quantum key-encapsulation mechanism (KEM) :
  • ML-KEM-768.KeyGen_internal(d, z): Deterministic algorithm to generate an ML-KEM-768 key pair (pk_M, sk_M) of an encapsulation key pk_M and decapsulation key sk_M. It is the derandomized version of ML-KEM-768.KeyGen. Note that ML-KEM-768.KeyGen_internal() returns the keys in reverse order of GenerateKeyPair() defined below. d and z are both 32 byte strings.
  • 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.Encaps(pk_M) MUST perform the encapsulation key check of §7.2 and raise an error if it fails.
  • ML-KEM-768.Decap(ct_M, sk_M): Deterministic algorithm using the decapsulation key sk_M to recover the shared key from ct_M. ML-KEM-768.Decap(ct_M, sk_M) is NOT required to perform the decapsulation key check of §7.3.
  To generate deterministic test vectors, we also use
  • ML-KEM-768.Encaps_internal(pk_M, m): 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. m is a 32 byte string. ML-KEM-768.Encaps_internal(pk_M) MUST perform the encapsulation key check of §7.2 and raise an error if it fails.
• X25519 elliptic curve Diffie-Hellman key-exchange defined in :
  • X25519(k, u): takes 32 byte strings k and u representing a Curve25519 scalar and the u-coordinate of a point respectively, and returns the 32 byte string representing the u-coordinate of their scalar multiplication.
  • X25519_BASE: the 32 byte string representing the standard base point of Curve25519. In hexadecimal, it is given by 0900000000000000000000000000000000000000000000000000000000000000.

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

• Symmetric cryptography.
  • SHAKE256(message, outlen): The extendable-output function (XOF) with that name defined in Section 6.2 of . Note that outlen counts bits.
  • SHA3-256(message): The hash with that name 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):

32 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 32 byte secret decapsulation key sk and the 1216 byte encapsulation key pk. Here and in the balance of the document for clarity we use the M and X subscripts for ML-KEM-768 and X25519 components respectively.

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. sk must be 32 bytes. GenerateKeyPairDerand() returns the 32 byte secret encapsulation key sk and the 1216 byte decapsulation key pk. Note GenerateKeyPair() is the same as GenerateKeyPairDerand(random(32)).

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 In hexadecimal, XWingLabel is given by 5c2e2f2f5e5c.

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. Note that Encapsulate() may raise an error if the ML-KEM encapsulation does not pass the check of §7.2.

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() eseed MUST be 64 bytes. EncapsulateDerand() returns the 32 byte shared secret ss and the 1120 byte ciphertext ct. Encapsulate(pk) can be implemented as EncapsulateDerand(pk,random(64)).

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

Keeping expanded decapsulation key around For efficiency, an implementation MAY cache the result of expandDecapsulationKey. This is useful in two cases:

1. If multiple ciphertexts for the same key are decapsulated.
2. If a ciphertext is decapsulated for a key that has just been generated. This happen on the client-side for TLS.

A typical API pattern to achieve this optimization is to have an opaque decapsulation key object that hides the cached values. For instance, such an API could have the following functions.

1. GenerateKeyPair() returns an encapsulation key and an opaque object that contains the expanded decapsulation key.
2. Decapsulate(ct, esk) takes a ciphertext and an expanded decapsulation key.
3. PackDecapsulationKey(sk) takes an expanded decapsulation key, and returns the packed decapsulation key.
4. UnpackDecapsulationKey(sk) takes a packed decapsulation key, and returns the expanded decapsulation key. In the case of X-Wing this would be the same as a derandomized GenerateKeyPair().

The expanded decapsulation key could cache even more computation, such as the expanded matrix A in ML-KEM. Any such expanded decapsulation key MUST NOT be transmitted between implementations, as this could break the security analysis of X-Wing. In particular, the MAL-BIND-K-PK and MAL-BIND-K-CT binding properties of X-Wing do not hold when transmitting the regular ML-KEM decapsulation key.

Use in HPKE X-Wing satisfies the HPKE KEM interface as follows. The SerializePublicKey, 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. Encap() is Encapsulate() from , where an ML-KEM encapsulation key check failure causes an HPKE EncapError. 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. On ML-KEM encapsulation key check failure, the server MUST abort with an illegal_parameter alert.

Use in X.509 Public Key Infrastructure We use the OID 1.3.6.1.4.1.62253.25722 to identify X-Wing keys as described below. In ASN.1 notation:

Certificate In a X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax. An X-Wing encapsulation key MUST be encoded directly using the ASN.1 type XWingPublicKey. The X-Wing encapsulation key is mapped to a subjectPublicKey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. The id-XWing identifier MUST be used as the algorithm field in the SubjectPublicKeyInfo to identify an X-Wing encapsulation key. The contents of the parameters component MUST be absent.

Private key Below we replicate part of the definition of OneAsymmetricKey from . When storing an X-Wing decapsulation key in a OneAsymmetricKey, the privateKey OCTET STRING contains the raw octet string encoding the X-Wing decapsulation key. The id-XWing identifier MUST be used as the algorithm field in the OneAsymmetricKey to identify an X-Wing decapsulation key. The publicKey component MUST be absent.

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, 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: the X-Wing combiner cannot be assumed to be secure, when used with different KEMs. In particular it is not known to be safe to leave out the post-quantum ciphertext from the combiner in the general case.

Binding properties Some protocols rely on further properties of the KEM. X-Wing satisfies the binding properties MAL-BIND-K-PK and MAL-BIND-K-CT (TODO: reference to proof). This implies X-Wing also satisfies

• MAL-BIND-K,CT-PK
• MAL-BIND-K,PK-CT
• LEAK-BIND-K-PK
• LEAK-BIND-K-CT
• LEAK-BIND-K,CT-PK
• LEAK-BIND-K,PK-CT
• HON-BIND-K-PK
• HON-BIND-K-CT
• HON-BIND-K,CT-PK
• HON-BIND-K,PK-CT

In contrast, ML-KEM on its own does not achieve MAL-BIND-K-PK, MAL-BIND-K-CT, nor MAL-BIND-K,PK-CT.

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

Value:

25722 = 25519 + 203 = 0x647a (please)

KEM:

X-Wing

Nsecret:

32

Nenc:

1120

Npk:

1216

Nsk:

32

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:

25722 = 25519 + 203 = 0x647a (please)

Description:

X-Wing

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

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

Finally, for the ASN.1 module in {asn1}, IANA is requested to assign an object identifier (OID) for the module identifier (TBD) with a Description of "id-mod-XWing-kem-2024".

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. ITU-T 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. This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] 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 and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 8447. n.d. n.d. n.d.

Implementations

• Platform
  • Apple CryptoKit
• C
  • Google's BoringSSL
• Go
  • Cloudflare's CIRCL
  • Filippo
• Rust
  • xwing-kem.rs Note: implements the older -00 version of this memo at the time of writing.
  • RustCrypto x-wing
  • Orion

Machine-readable specification For the convenience of implementors, we provide a reference specification in Python. This is a specification; not production ready code: it should not be deployed as-is, as it leaks the private key by its runtime.

xwing.py

x25519.py > t) & 1 swap ^= kt if swap == 1: x3, x2 = x2, x3 z3, z2 = z2, z3 swap = kt A = x2 + z2 AA = (A*A) % p B = x2 - z2 BB = (B*B) % p E = AA - BB C = x3 + z3 D = x3 - z3 DA = (D*A) % p CB = (C*B) % p x3 = DA + CB x3 = (x3 * x3) % p z3 = DA - CB z3 = (x1 * z3 * z3) % p x2 = (AA * BB) % p z2 = (E * (AA + (a24 * E) % p)) % p if swap == 1: x3, x2 = x2, x3 z2, z3 = z3, z2 ret = (x2 * pow(z2, p-2, p)) % p return bytes((ret >> 8*i) & 255 for i in range(32)) ]]>

mlkem.py

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

Example of use in X.509 The following are the encodings of the X-Wing keypair with private key 0001…1f.

ASN.1 Module This appendix includes the ASN.1 module for X-Wing.

Acknowledgments TODO acknowledge.

Change log

• RFC Editor's Note: Please remove this section prior to publication of a final version of this document.

Since draft-connolly-cfrg-xwing-kem-07

• Elaborate on relation between randomized and derandomized functions.
• Update implementations section.

Since draft-connolly-cfrg-xwing-kem-06

• Add asn.1 module.
• To match FIPS 202, we request number of bits from SHAKE-256 instead of number of bytes. #27
• Update implementations section.
• Correct PEM header. #25

Since draft-connolly-cfrg-xwing-kem-05

• Fix several typos.
• Change HPKE/TLS codepoint requests to the memorable 25519 + 203.
• Add instruction for use in X.509. #21

Since draft-connolly-cfrg-xwing-kem-04

• Note that ML-KEM decapsulation key check is not required.
• Properly refer to FIPS 203 dependencies. #20
• Move label at the end. As everything fits within a single block of SHA3-256, this does not make any difference.
• Use SHAKE-256 to stretch seed. This does not have any security or performance effects: as we only squeeze 96 bytes, we perform a single Keccak permutation whether SHAKE-128 or SHAKE-256 is used. The effective capacity of the sponge in both cases is 832, which gives a security of 416 bits. It does require less thought from anyone analysing X-Wing in a rush.
• Add HPKE codepoint.
• Don't mark TLS entry as recommended before it has been through the IETF consensus process. (Obviously the authors recommend X-Wing.)

Since draft-connolly-cfrg-xwing-kem-03

• Mandate ML-KEM encapsulation key check, and stipulate effect on TLS and HPKE integration.
• Add provisional TLS codepoint. (Not assigned, yet.)

Since draft-connolly-cfrg-xwing-kem-02

• Use seed as private key.
• Expand on caching decapsulation key values.
• Expand on binding properties.

Since draft-connolly-cfrg-xwing-kem-01

• Add list of implementations.
• Miscellaneous editorial improvements.
• Add Python reference specification.
• Correct definition of ML-KEM-768.KeyGenDerand(seed).

Since draft-connolly-cfrg-xwing-kem-00

• A copy of the X25519 public key is now included in the X-Wing decapsulation (private) key, so that decapsulation does not require separate access to the X-Wing public key. See #2.