]>
XWing: generalpurpose hybrid postquantum KEM
SandboxAQ
durumcrustulum@gmail.com
MPISP & Radboud University
peter@cryptojedi.org
Cloudflare
bas@cloudflare.com
IRTF
Crypto Forum
post quantum
kem
PQ/T hybrid
This memo defines XWing, a generalpurpose postquantum/traditional
hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and
MLKEM768.
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: MLKEM768 has not been standardised
XWing uses MLKEM768, which has not been standardised yet. Thus XWing
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 XWing is to provide a concrete, simple choice for
postquantum 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
XWing.

Simplicity of definition. Because all shared secrets and cipher texts
are fixed length, we do not need to encode the length. Using SHA3256,
we do not need HMACbased construction. For the concrete choice of
MLKEM768, we do not need to mix in its ciphertext, see .

Security analysis. Because MLKEM768 already assumes QROM, we do not
need to complicate the analysis of XWing by considering stronger
models.

Performance. Not having to mix in the MLKEM768 ciphertext is a nice
performance benefit. Furthermore, by using SHA3256 in the combiner,
which matches the hashing in MLKEM768, this hash can be computed in
one go on platforms where twoway Keccak is available.
We aim for "128 bits" security (NIST PQC level 1). Although at the
moment there is no peerreviewed evidence that MLKEM512 does not reach
this level, we would like to hedge against future cryptanalytic
improvements, and feel MLKEM768 provides a comfortable margin.
We aim for XWing to be usable for most applications, including
specifically HPKE .
Not an interactive keyagreement
Traditionally most protocols use a DiffieHellman (DH) style
noninteractive keyagreement. In many cases, a DH key agreement can be
replaced by the interactive keyagreement 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
straightforward manner by a plain KEM.
Not an authenticated KEM
In particular, XWing is not, borrowing the language of , an
authenticated KEM.
Comparisons
With HPKE X25519Kyber768Draft00
XWing is most similar to HPKE's X25519Kyber768Draft00
. The key differences are:

XWing uses the final version of MLKEM768.

XWing hashes the shared secrets, to be usable outside of HPKE.

XWing has a simpler combiner by flattening DHKEM(X25519) into the
final hash.

XWing does not hash in the MLKEM768 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 MLKEM768 and DHKEM(X25519). That achieves similar
security, but:

XWing is more performant, not hashing in the MLKEM768 ciphertext,
and flattening the DHKEM construction, with the same level of
security.

XWing has a fixed 32 byte shared secret, instead of a variable shared
secret.

XWing 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 cryptographicallysecure random number generator.
Cryptographic Dependencies
XWing relies on the following primitives:

MLKEM768 postquantum keyencapsulation mechanism (KEM) :

MLKEM768.KeyGen(): Randomized algorithm to generate an
MLKEM768 key pair (pk_M, sk_M) of an encapsulation key pk_M
and decapsulation key sk_M.
Note that MLKEM768.KeyGen() returns the keys in reverse
order of GenerateKeyPair() defined below.

MLKEM768.Encaps(pk_M): Randomized algorithm to generate (ss_M,
ct_M), an ephemeral 32 byte shared key ss_M, and a fixedlength
encapsulation (ciphertext) of that key ct_M for encapsulation key
pk_M.

MLKEM768.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

MLKEM768.KeyGenDerand(seed): Same as MLKEM768.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).

MLKEM768.EncapsDerand(pk_M, seed): Same as MLKEM768.Encaps()
but derandomized as follows.
seed is 32 bytes and used for m (line 1 algorithm 16).

X25519 elliptic curve DiffieHellman keyexchange 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 extendableoutput function (XOF)
defined in Section 6.2 of .

SHA3256(message): The hash defined in
defined in Section 6.1 of .
XWing Construction
Encoding and sizes
XWing encapsulation key, decapsulation key, ciphertexts and shared secrets are all
fixed length byte strings.
 Decapsulation key (private):

2464 bytes
 Encapsulation key (public):

1216 bytes
 Ciphertext:

1120 bytes
 Shared secret:

32 bytes
Key generation
An XWing keypair (decapsulation key, encapsulation key) is generated as
follows.
GenerateKeyPair() returns the 2464 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 XWing implementation MAY provide the following
derandomized variant of key generation.
seed must be 96 bytes.
GenerateKeyPairDerand() returns the 2464 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
MLKEM768 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 XWing encapsulation key pk, encapsulation proceeds as follows.
pk is a 1216 byte XWing 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 XWing implementation MAY provide
the following derandomized function.
pk is a 1216 byte XWing 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 2464 byte XWing decapsulation key resulting from GenerateKeyPair()
Decapsulate() returns the 32 byte shared secret.
Use in HPKE
XWing satisfies the HPKE KEM interface as follows.
The SerializePublicKey, DeserializePublicKey,
SerializePrivateKey and DeserializePrivateKey are the identity functions,
as XWing keys are fixedlength byte strings, see .
DeriveKeyPair() is given by
where the HPKE private key and public key are the XWing 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 .
XWing 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 XWing encapsulation key.
For the server's share, the key_exchange value contains
the XWing ciphertext.
Security Considerations
Informally, XWing is secure if SHA3 is secure, and either X25519 is
secure, or MLKEM768 is secure.
More precisely, if SHA3256, SHA3512, SHAKE128, and SHAKE256 may be
modelled as a random oracle, then the INDCCA security of XWing is
bounded by the INDCCA security of MLKEM768, and the gapCDH security
of Curve25519, see .
The security of XWing relies crucially on the specifics of the
FujisakiOkamoto transformation used in MLKEM768. In particular, the
XWing 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:

XWing
 Nsecret:

32
 Nenc:

1120
 Npk:

1216
 Nsk:

2464
 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:

XWing
 DTLSOK:

Y
 Recommended:

Y
 Reference:

This document
 Comment:

PQ/T hybrid of X25519 and MLKEM768
TODO

Which validation do we want to require?
References
Normative References
Key words for use in RFCs to Indicate Requirement Levels
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.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
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
Terminology for PostQuantum Traditional Hybrid Schemes
UK National Cyber Security Centre
One aspect of the transition to postquantum algorithms in
cryptographic protocols is the development of hybrid schemes that
incorporate both postquantum 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.
Combiner function for hybrid key encapsulation mechanisms (Hybrid KEMs)
Entrust Limited
Proton AG
BSI
The migration to postquantum 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 80056Cr2 [SP80056C] when viewed as a key
derivation function. The combiners defined here are practical split
key PRFs and are CCAsecure as long as at least one of the ingredient
KEMs is.
FIPS 202: SHA3 Standard: PermutationBased Hash and ExtendableOutput Functions
n.d.
FIPS 203 (Initial Draft): ModuleLatticeBased KeyEncapsulation Mechanism Standard
n.d.
Hybrid Public Key Encryption
This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrarysized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a preshared 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 DiffieHellman (ECDH) key agreement, HMACbased key derivation function (HKDF), and SHA2.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
Elliptic Curves for Security
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 ~128bit and ~224bit security level, respectively, and are generated deterministically based on a list of required properties.
Hybrid key exchange in TLS 1.3
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 postquantum 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/draftstebilatlshybrid
design.
X25519Kyber768Draft00 hybrid postquantum KEM for HPKE
Cloudflare
Cloudflare
This memo defines X25519Kyber768Draft00, a hybrid postquantum KEM,
for HPKE (RFC9180). This KEM does not support the authenticated
modes of HPKE.
X25519Kyber768Draft00 hybrid postquantum key agreement
Cloudflare
University of Waterloo
This memo defines X25519Kyber768Draft00, a hybrid postquantum key
exchange for TLS 1.3.
IANA Registry Updates for TLS and DTLS
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.
XWing: The Hybrid KEM You’ve Been Looking For
n.d.
Test vectors # TODO: replace with test vectors that reuse MLKEM, X25519 values
Acknowledgments
TODO acknowledge.
Change log

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

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