]>
PQ/T Hybrid KEM: HPKE with JOSE/COSE
Nokia
Bangalore
Karnataka
India
kondtir@gmail.com
Germany
hannes.tschofenig@gmx.net
Security
COSE
PQC
COSE
JOSE
Hybrid
HPKE
This document outlines the construction of a PQ/T Hybrid Key Encapsulation Mechanism (KEM) in Hybrid PublicKey Encryption (HPKE) for integration with JOSE and COSE. It specifies the utilization of both traditional and PostQuantum Cryptography (PQC) algorithms, referred to as PQ/T Hybrid KEM, within the context of JOSE and COSE.
About This Document
Status information for this document may be found at .
Discussion of this document takes place on the
cose Working Group mailing list (),
which is archived at .
Subscribe at .
Introduction
The migration to PostQuantum Cryptography (PQC) is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the postquantum algorithms are fully trusted to protect data for the required data lifetimes. The traditional algorithms, such as RSA and elliptic curve, will fall to quantum cryptalanysis, while the postquantum algorithms face uncertainty about the underlying mathematics, compliance issues, unknown vulnerabilities, hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs.
During the transition from traditional to postquantum algorithms, there is a desire or a requirement for protocols that use both algorithm types. 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.
HPKE offers a variant of publickey encryption of arbitrarysized plaintexts for a recipient public key. The specifications for the use of HPKE with JOSE and COSE are described in and , respectively. HPKE can be extended to support PQ/T Hybrid KEM as defined in . This specification defines PQ/T Hybrid KEM in HPKE for use with JOSE and COSE.
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.
This document makes use of the terms defined in . For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into two classes:
"Traditional Algorithm": An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems. In the context of JOSE, examples of traditional key exchange algorithms include Elliptic Curve DiffieHellman Ephemeral Static . In the context of COSE, examples of traditional key exchange algorithms include EphemeralStatic (ES) DH and StaticStatic (SS) DH .
"PostQuantum Algorithm": An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers. Examples of PQC key exchange algorithms include MLKEM.
"PostQuantum Traditional (PQ/T) Hybrid Scheme": A multialgorithm scheme where at least one component algorithm is a postquantum algorithm and at least one is a traditional algorithm.
"PQ/T Hybrid Key Encapsulation Mechanism": A multialgorithm KEM made up of two or more component KEM algorithms where at least one is a postquantum algorithm and at least one is a traditional algorithm.
Construction
MLKEM is a onepass (storeandforward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's MLKEM public key. Three parameters sets for MLKEMs are specified by . In order of increasing security strength (and decreasing performance), these parameter sets
are MLKEM512, MLKEM768, and MLKEM1024. uses a multialgorithm scheme,
where one component algorithm is a postquantum algorithm and another one is a traditional algorithm. The Combiner function defined in Section 5.3 of combines the output of a postquantum KEM and a traditional KEM to generate a single shared secret.
Ciphersuite Registration
This specification registers a number of PQ/T Hybrid KEMs for use with HPKE. A ciphersuite is thereby a combination of several algorithm configurations:

HPKE Mode

KEM algorithm (Traditional Algorithm + PQ KEM, for example, X25519Kyber768)

KDF algorithm

AEAD algorithm
The "KEM", "KDF", and "AEAD" values are conceptually taken from the HPKE IANA registry . Hence, JOSE and COSE cannot use an algorithm combination that is not already available with HPKE.
The HPKE PQ/T hybrid ciphersuites for JOSE and COSE are defined in .
Security Considerations
The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. PQC KEMs used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused, such as achieving INDCCA2 security. MLKEM has such security properties.
IANA Considerations
JOSE
This document requests IANA to add new values to the "JSON Web Signature and Encryption Algorithms" registry.
JOSE Algorithms Registry

Algorithm Name: HPKEBaseX25519Kyber768SHA256AES256GCM

Algorithm Description: Cipher suite for JOSEHPKE in Base Mode that uses the X25519Kyber768Draft00 Hybrid
KEM, the HKDFSHA256 KDF, and the AES256GCM AEAD.

Algorithm Usage Location(s): "alg, enc"

JOSE Implementation Requirements: Optional

Change Controller: IANA

Specification Document(s): [[TBD: This RFC]]

Algorithm Analysis Documents(s): TODO

Algorithm Name: HPKEBaseX25519Kyber768SHA256ChaCha20Poly1305

Algorithm Description: Cipher suite for JOSEHPKE in Base Mode that uses the X25519Kyber768Draft00 Hybrid
KEM, the HKDFSHA256 KDF, and the ChaCha20Poly1305 AEAD.

Algorithm Usage Location(s): "alg, enc"

JOSE Implementation Requirements: Optional

Change Controller: IANA

Specification Document(s): [[TBD: This RFC]]

Algorithm Analysis Documents(s): TODO
COSE
This document requests IANA to add new values to the 'COSE Algorithms' registry.
COSE Algorithms Registry

Name: HPKEBaseX25519Kyber768SHA256AES256GCM

Value: TBD1

Description: Cipher suite for COSEHPKE in Base Mode that uses the X25519Kyber768Draft00 Hybrid KEM, the
HKDFSHA256 KDF, and the AES256GCM AEAD.

Capabilities: [kty]

Change Controller: IANA

Reference: [[TBD: This RFC]]

Name: HPKEBaseX25519Kyber768SHA256ChaCha20Poly1305

Value: TBD2

Description: Cipher suite for COSEHPKE in Base Mode that uses the X25519Kyber768Draft00 Hybrid
KEM, the HKDFSHA256 KDF, and the ChaCha20Poly1305 AEAD.

Capabilities: [kty]

Change Controller: IANA

Reference: [[TBD: This RFC]]
Acknowledgments
Thanks to Ilari Liusvaara for the discussion and comments.
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
ModuleLatticebased KeyEncapsulation Mechanism Standard
Hybrid Public Key Encryption (HPKE) IANA Registry
IANA
Use of Hybrid PublicKey Encryption (HPKE) with Javascript Object Signing and Encryption (JOSE)
Nokia
Nokia
Transmute
independent
This specification defines Hybrid publickey encryption (HPKE) for
use with Javascript Object Signing and Encryption (JOSE). HPKE
offers a variant of publickey encryption of arbitrarysized
plaintexts for a recipient public key.
HPKE works for any combination of an asymmetric key encapsulation
mechanism (KEM), key derivation function (KDF), and authenticated
encryption with additional data (AEAD) function. Authentication for
HPKE in JOSE is provided by JOSEnative security mechanisms or by one
of the authenticated variants of HPKE.
This document defines the use of the HPKE with JOSE.
Use of Hybrid PublicKey Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)
Transmute
Security Theory LLC
This specification defines hybrid publickey encryption (HPKE) for
use with CBOR Object Signing and Encryption (COSE). HPKE offers a
variant of publickey encryption of arbitrarysized plaintexts for a
recipient public key.
HPKE works for any combination of an asymmetric key encapsulation
mechanism (KEM), key derivation function (KDF), and authenticated
encryption with additional data (AEAD) function. Authentication for
HPKE in COSE is provided by COSEnative security mechanisms or by one
of the authenticated variants of HPKE.
This document defines the use of the HPKE with COSE.
XWing: generalpurpose hybrid postquantum KEM
SandboxAQ
MPISP & Radboud University
Cloudflare
This memo defines XWing, a generalpurpose postquantum/traditional
hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML
KEM768.
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.
Fundamental Elliptic Curve Cryptography Algorithms
This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.
CFRG Elliptic Curve DiffieHellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)
This document defines how to use the DiffieHellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).
CBOR Object Signing and Encryption (COSE): Structures and Process
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.
This document, along with RFC 9053, obsoletes RFC 8152.