PQ/T Hybrid KEM: HPKE with JOSE/COSE

Introduction The migration to Post-Quantum Cryptography (PQC) is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the post-quantum 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 cryptanalysis, while the post-quantum 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 post-quantum 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 post-quantum cryptography. HPKE offers a variant of public-key encryption of arbitrary-sized 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 Diffie-Hellman Ephemeral Static . In the context of COSE, examples of traditional key exchange algorithms include Ephemeral-Static (ES) DH and Static-Static (SS) DH . "Post-Quantum 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 ML-KEM. "Post-Quantum Traditional (PQ/T) Hybrid Scheme": A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm. "PQ/T Hybrid Key Encapsulation Mechanism": A multi-algorithm KEM made up of two or more component KEM algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.

Construction ML-KEM is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's ML-KEM public key. Three parameter sets for ML-KEMs are specified by . In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. PQ/T algorithms for HPKE use a multi-algorithm scheme, where one component algorithm is a post-quantum algorithm and another one is a traditional algorithm. The C2PRICombiner combiner function defined in Sections 5.1.3 of combines the output of a post-quantum KEM and a traditional KEM to generate a single shared secret.

Alignment with JOSE HPKE Modes The JOSE HPKE specification defines two different HPKE usage modes:

Integrated Encryption Mode – HPKE is used directly to encrypt the plaintext for a recipient.
Key Encryption Mode – HPKE is used only to encrypt the Content Encryption Key (CEK), and the CEK is then used to encrypt the payload.

Each mode is associated with a separate JOSE alg identifier. To maintain consistency with the JOSE HPKE specification, this document registers distinct PQ/T Hybrid HPKE algorithms for Integrated Encryption and Key Encryption. The PQ/T Hybrid KEM is the same in both cases, but the JWE-level processing and algorithm identifiers differ. This separation ensures that JOSE implementations can correctly determine how the PQ/T Hybrid KEM is used based solely on the alg value, without ambiguity.

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:

KEM algorithm (PQ KEM + Traditional Algorithm, for example, MLKEM768 + X25519 defined as "MLKEM768-X25519" in )
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 . Note that the PQ/T Hybrid KEM in HPKE is not an authenticated KEM. The HPKE Base mode can only be supported with the PQ/T Hybrid KEM.

AKP Key for PQ/T Hybrid Algorithms in HPKE This section describes the required parameters for an "AKP" key type, as defined in , and its use with the PQ/T Hybrid Algorithms for HPKE, as defined in {#XWING} and {#XWING-KE}. An example JWK is also provided for illustration.

Required Parameters A JSON Web Key (JWK) or COSE_Key with a key type ("kty") for use with the PQ/T Hybrid Algorithm for HPKE includes the following parameters:

kty (Key Type)
The key type parameter MUST be present and set to "AKP".
alg (Algorithm)
The algorithm parameter MUST be present and MUST represent the PQ/T algorithm for HPKE, as defined in {#XWING} or {#XWING-KE}. PQ/T algorithms for HPKE are those registered in the "JSON Web Signature and Encryption Algorithms" and "COSE Algorithms" registries, derived from the KEM identifier in the HPKE IANA registry.
pub (Public Key)
The public key parameter MUST be present and MUST contain the public encapsulation key (pk) as defined in Section 5.1 of . When represented as a JWK, this value MUST be base64url-encoded.
priv (Private Key)
When representing a private key, the private key parameter MUST be present and MUST contain the private decapsulation key (sk) as defined in Section 5.1 of . When represented as a JWK, this value MUST be base64url-encoded.

Example The following is an example JWK representation of an "AKP" key for the "MLKEM768-X25519-SHA3256-AES-256-GCM" algorithm:

Security Considerations The security considerations in , and are to be taken into account. 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 IND-CCA2 security. ML-KEM has such security properties.

Post-Quantum Security for Multiple Recipients In HPKE JWE Key Encryption, when encrypting the Content Encryption Key (CEK) for multiple recipients, it is crucial to consider the security requirements of the message to safeguard against "Harvest Now, Decrypt Later" attacks. For messages requiring post-quantum security, all recipients MUST use algorithms supporting post-quantum cryptographic methods, such as PQC KEMs or Hybrid PQ/T KEMs. Using traditional algorithms (e.g., ECDH-ES) for any recipient in these scenarios compromises the overall security of the message.

IANA Considerations

JOSE This document requests IANA to add new values to the "JSON Web Signature and Encryption Algorithms" registry.

JOSE Algorithms for Integrated Encryption

Algorithm Name: HPKE-7
Algorithm Description: Integrated Encryption with HPKE that uses the P-256 + ML-KEM-768 Hybrid KEM, the SHA3-256 KDF, and the AES-256-GCM AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Documents(s): TODO
Algorithm Name: HPKE-8
Algorithm Description: Integrated Encryption with HPKE that uses the P-256 + ML-KEM-768 Hybrid KEM, the SHA3-256 KDF, and the ChaCha20Poly1305 AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Documents(s): TODO
Algorithm Name: HPKE-9
Algorithm Description: Integrated Encryption with HPKE that uses the X25519 + ML-KEM-768 Hybrid KEM, the SHA3-256 KDF, and the AES-256-GCM AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Documents(s): TODO
Algorithm Name: HPKE-10
Algorithm Description: Integrated Encryption with HPKE that uses the X25519 + ML-KEM-768 Hybrid KEM, the SHA3-256 KDF, and the ChaCha20Poly1305 AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Documents(s): TODO
Algorithm Name: HPKE-11
Algorithm Description: Integrated Encryption with HPKE that uses the P-384 + ML-KEM-1024 Hybrid KEM, the SHA3-256 KDF, and the AES-256-GCM AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Documents(s): TODO
Algorithm Name: HPKE-12
Algorithm Description: Integrated Encryption with HPKE that uses the P-384 + ML-KEM-1024 Hybrid KEM, the SHA3-256 KDF, and the ChaCha20Poly1305 AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Documents(s): TODO

JOSE Algorithms for Key Encryption

Algorithm Name: HPKE-7-KE
Algorithm Description: Key Encryption with HPKE that uses the P-256 + ML-KEM-768 Hybrid KEM, the SHA3-256 KDF, and the AES-256-GCM AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Document(s): TODO
Algorithm Name: HPKE-8-KE
Algorithm Description: Key Encryption with HPKE that uses the P-256 + ML-KEM-768 Hybrid KEM, the SHA3-256 KDF, and the ChaCha20Poly1305 AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Document(s): TODO
Algorithm Name: HPKE-9-KE
Algorithm Description: Key Encryption with HPKE that uses the X25519 + ML-KEM-768 Hybrid KEM, the SHA3-256 KDF, and the AES-256-GCM AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Document(s): TODO
Algorithm Name: HPKE-10-KE
Algorithm Description: Key Encryption with HPKE that uses the X25519 + ML-KEM-768 Hybrid KEM, the SHA3-256 KDF, and the ChaCha20Poly1305 AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Document(s): TODO
Algorithm Name: HPKE-11-KE
Algorithm Description: Key Encryption with HPKE that uses the P-384 + ML-KEM-1024 Hybrid KEM, the SHA3-256 KDF, and the AES-256-GCM AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Document(s): TODO
Algorithm Name: HPKE-12-KE
Algorithm Description: Key Encryption with HPKE that uses the P-384 + ML-KEM-1024 Hybrid KEM, the SHA3-256 KDF, and the ChaCha20Poly1305 AEAD.
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Document(s): TODO

COSE This document requests IANA to add new values to the 'COSE Algorithms' registry.

COSE Algorithms Registry

Name: MLKEM768-P256-SHA3256-AES-256-GCM
Value: TBD1
Description: Cipher suite for COSE-HPKE in Base Mode that uses the ML-KEM-768 + P-256 Hybrid KEM, the SHA3-256 KDF, and the AES-256-GCM AEAD.
Capabilities: [kty]
Change Controller: IANA
Reference: [[TBD: This RFC]]
Name: MLKEM768-P256-SHA3256-ChaCha20Poly1305
Value: TBD2
Description: Cipher suite for COSE-HPKE in Base Mode that uses the ML-KEM-768 + P-256 Hybrid KEM, the SHA3-256 KDF, and the ChaCha20Poly1305 AEAD.
Capabilities: [kty]
Change Controller: IANA
Reference: [[TBD: This RFC]]
Name: MLKEM768-X25519-SHA3256-AES-256-GCM
Value: TBD3
Description: Cipher suite for COSE-HPKE in Base Mode that uses the ML-KEM-768 + X25519 Hybrid KEM, the SHA3-256 KDF, and the AES-256-GCM AEAD.
Capabilities: [kty]
Change Controller: IANA
Reference: [[TBD: This RFC]]
Name: MLKEM768-X25519-SHA3256-ChaCha20Poly1305
Value: TBD4
Description: Cipher suite for COSE-HPKE in Base Mode that uses the ML-KEM-768 + X25519 Hybrid KEM, the SHA3-256 KDF, and the ChaCha20Poly1305 AEAD.
Capabilities: [kty]
Change Controller: IANA
Reference: [[TBD: This RFC]]
Name: MLKEM1024-P384-SHA3256-AES-256-GCM
Value: TBD5
Description: Cipher suite for COSE-HPKE in Base Mode that uses the ML-KEM-1024 + P-384 Hybrid KEM, the SHA3-256 KDF, and the AES-256-GCM AEAD.
Capabilities: [kty]
Change Controller: IANA
Reference: [[TBD: This RFC]]
Name: MLKEM1024-P384-SHA3256-ChaCha20Poly1305
Value: TBD6
Description: Cipher suite for COSE-HPKE in Base Mode that uses the ML-KEM-1024 + P-384 Hybrid KEM, the SHA3-256 KDF, and the ChaCha20Poly1305 AEAD.
Capabilities: [kty]
Change Controller: IANA
Reference: [[TBD: This RFC]]

Acknowledgments Thanks to Ilari Liusvaara and Orie Steele for the discussion and comments.