]> Cloudflare

bas@cloudflare.com

Cloudflare

caw@heapingbits.net

IRTF Crypto Forum kyber post-quantum x25519 hpke This memo defines X25519Kyber768Draft00, a hybrid post-quantum KEM, for HPKE (RFC9180). This KEM does not support the authenticated modes of HPKE. 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 The final draft for Kyber is expected in 2024. There is a desire to deploy post-quantum cryptography earlier than that. To promote interoperability of early implementations, this document specifies a preliminary hybrid post-quantum key agreement.

Not an authenticated KEM Kyber is a plain KEM that does not support the static-ephemeral key exchange that allows HPKE based on Diffie-Hellman based KEMs its (optional) authenticated modes.

Conventions and Definitions 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.

Construction In short, X25519Kyber768Draft00 is the parallel combination of DHKEM(X25519, HKDF-SHA256) and Kyber768Draft00 : wire encodings of public key, private key, cipher texts and shared secrets are simple concatenations. A KEM private key is a tuple of an DHKEM(X25519, HKDF-SHA256) private key and Kyber768Draft00 private key, where each is an octet string of length 32 and 2400 bytes, respectively. Similarly, a KEM public key is a tuple of an DHKEM(X25519, HKDF-SHA256) public key and Kyber768Draft00 public key. Kyber768Draft00 is Kyber768 as submitted to the third round of the NIST PQC process , where it is also known as v3.02. Note that this hybrid KEM is different from the one defined in based on for TLS, as raw X25519 shared secrets can be used, thanks to the message transcript. We use HKDF-SHA256 as the HPKE HKDF. We denote the DHKEM(X25519, HKDF-SHA256) KEM as DHKEM throughout the document.

SerializePublicKey and DeserializePublicKey SerializePublicKey and DeserializePublicKey encode and decode X25519Kyber768Draft00 public keys to and from their wire format representation. Their implementation is described below. Note that DHKEM public keys MUST be validated before they can be used as stipulated in . DHKEM.SerializePublicKey() and DHKEM.DeserializePublicKey() are SerializePublicKey() and respectively DeserializePublicKey() as defined for DHKEM in .

SerializePrivateKey and DeserializePrivateKey SerializePrivateKey and DeserializePrivateKey encode and decode X25519Kyber768Draft00 private keys to and from their wire format representation. Their implementation is described below. DHKEM.SerializePrivateKey() and DHKEM.DeserializePrivateKey() are SerializePrivateKey() and respectively DeserializePrivateKey() as defined for DHKEM in .

DeriveKeyPair DeriveKeyPair deterministically derives a X25519Kyber768Draft00 private and public key pair from a fixed-length seed. In particular, a single seed is stretched and passed to the relevant key derivation functions for DHKEM and Kyber768Draft00. DHKEM.DeriveKeyPair() is DeriveKeyPair() defined for DHKEM in . Kyber768Draft00.DeriveKeyPair() is the key generation as defined in . ikm 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 and Decap Encap and Decap are the primary KEM functions. Their implementation is described below.

AuthEncap and AuthDecap X25519Kyber768Draft00 is not an authenticeted KEM and does not support AuthEncap() or AuthDecap(), see .

Security Considerations We aim for IND-CCA2 robustness: that means that if either constituent KEM is not IND-CCA2 secure, but the other is, the combined hybrid remains IND-CCA2 secure. In general this requires a combiner that mixes in the cipher texts, such as, assuming fixed-length cipher texts and shared secrets: In the present case, DHKEM(X25519, -) and Kyber768Draft00 already mix in the respective cipher texts into their shared secrets. Thus we can forgo mixing in the cipher texts a second time. Furthermore, in HPKE, the shared secret is never used directly, but passed through HKDF (via KeySchedule), and thus we can forgo the call to HKDF as well.

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

Value:

0x30 (please)

KEM:

X25519Kyber768Draft00

Nsecret:

64

Nenc:

1120

Npk:

1216

Nsk:

2432

Auth:

no

Reference:

This document

References Normative References 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. 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. MPI-SPI & Radboud University Cloudflare This memo specifies a preliminary version ("draft00", "v3.02") of Kyber, an IND-CCA2 secure Key Encapsulation Method. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg- schwabe-kyber.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/. Source for this draft and an issue tracker can be found at https://github.com/bwesterb/draft-schwabe-cfrg-kyber. 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 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 multi- PRFs and are CCA-secure as long as at least one of the ingredient KEMs is. 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-ietf-tls-hybrid-design. Cloudflare University of Waterloo This memo defines X25519Kyber768Draft00, a hybrid post-quantum key exchange for TLS 1.3.

Acknowledgements The authors would like to thank P. Kampanakis, I. Liusvaara, T. Wiggers, and S. Farrell for their input.

Change log

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

Since draft-westerbaan-cfrg-hpke-xyber768d00-00

• Add acknowledgements.
• Elaborate on missing authenticated modes.
• Add test vectors for the PSK mode.

Test Vectors This section contains test vectors formatted similary to that which are found in , except that it only contains vectors for the non-authenticated modes of operation.

DHKEM(X25519, HKDF-SHA256)+Kyber768Draft00, HKDF-SHA256, AES-128-GCM

Base Setup Information

Encryptions

Exported Values

PSK Setup Information

Encryptions

Exported Values