]>
Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSENokiaBangaloreKarnatakaIndiakondtir@gmail.comNokiaMunichGermanyaritra.banerjee@nokia.comGermanyhannes.tschofenig@gmx.net
Security
COSEPQCCOSEJOSEHybridThis document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within 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 .
IntroductionQuantum computing is no longer perceived as a conjecture of computational sciences and theoretical physics. Considerable research efforts and enormous corporate and government funding for the development of practical quantum computing systems are being invested currently. As such, as quantum technology advances, there is the potential for future quantum computers to have a significant impact on current cryptographic systems.Researchers have developed Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) to provide secure key establishment resistant against an adversary with access to a quantum computer.As the National Institute of Standards and Technology (NIST) is still in the process of selecting the new post-quantum cryptographic algorithms that are secure against both quantum and classical computers, the purpose of this document is to propose a PQ-KEMs to protect the confidentiality of content encrypted using JOSE and COSE against the quantum threat.Although this mechanism could thus be used with any PQ-KEM, this document focuses on Module-Lattice-based Key Encapsulation Mechanisms (ML-KEMs). 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 parameters 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.Conventions and DefinitionsThe 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 . The following terms are repeately used in this specification:
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 or elliptic curve discrete logarithms. 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. Post-quantum algorithms can also be called quantum-resistant or quantum-safe algorithms. Examples of Post-Quantum Algorithm include ML-KEM.Key Encapsulation MechanismsFor the purposes of this document, we consider a Key Encapsulation Mechanism (KEM) to be any asymmetric cryptographic scheme comprised of algorithms satisfying the following interfaces .
def kemKeyGen() -> (pk, sk)
def kemEncaps(pk) -> (ct, ss)
def kemDecaps(ct, sk) -> ss
where pk is public key, sk is secret key, ct is the ciphertext representing an encapsulated key, and ss is shared secret.KEMs are typically used in cases where two parties, hereby refereed to as the "encapsulater" and the "decapsulater", wish to establish a shared secret via public key cryptography, where the decapsulater has an asymmetric key pair and has previously shared the public key with the encapsulater.Design RationalesSection 4.6 of the JSON Web Algorithms (JWA) specification, see , defines two ways of using a key agreement:
When Direct Key Agreement is employed, the shared secret established through the Traditional Algorithm will be the content encryption key (CEK).
When Key Agreement with Key Wrapping is employed, the shared secret established through the Traditional Algorithm will wrap the CEK.
For efficient use with multiple recipient the key wrap approach is used since the content can be encrypted once with the CEK but each CEK is encrypted per recipient. Similarly, Section 8.5.4 and Section 8.5.5 of COSE define the Direct Key Agreement and Key Agreement with Key Wrap, respectively. This document proposes the use of PQ-KEMs for these two modes.It is essential to note that in the PQ-KEM, one needs to apply Fujisaki-Okamoto transform or its variant on the PQC KEM part to ensure that the overall scheme is IND-CCA2 secure, as mentioned in . The FO transform is performed using the KDF such that the PQC KEM shared secret achieved is IND-CCA2 secure. As a consequence, one can re-use PQC KEM public keys but there is an upper bound that must be adhered to.Note that during the transition from traditional to post-quantum algorithms, there may be a desire or a requirement for protocols that incorporate both types of algorithms until the post-quantum algorithms are fully trusted. HPKE is an KEM that can be extended to support hybrid post-quantum KEMs and the specifications for the use of HPKE with JOSE and COSE are described in and , respectively.KEM PQC AlgorithmsThe National Institute of Standards and Technology (NIST) started a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms, as seen here. Said process has reached its first announcement in July 5, 2022, which stated which candidates to be standardized for KEM:
Key Encapsulation Mechanisms (KEMs): CRYSTALS-Kyber: ML-KEM, previously known
as Kyber, is a module learning with errors (MLWE)-based KEM. Three security levels have been defined in the NIST PQC Project, namely Level 1, 3, and 5. These levels correspond to the hardness of breaking AES-128, AES-192 and AES-256, respectively.
NIST announced as well that they will be opening a fourth round to standardize an alternative KEM, and a call for new candidates for a post-quantum signature algorithm.ML-KEMML-KEM offers several parameter sets with varying levels of security and performance trade-offs. This document specifies the use of the ML-KEM algorithm at three security levels: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. ML-KEM key generation, encapsulation and decaspulation functions are defined in . The main security property for KEMs standardized in the NIST Post-Quantum Cryptography Standardization Project is indistinguishability under adaptive chosen ciphertext attacks (IND-CCA2) (see Section 10.2 of ). The public/private key sizes, ciphertext key size, and PQ security levels of ML-KEM are detailed in Section 12 of .PQ-KEM EncapsulationThe encapsulation process is as follows:
Generate an inital shared secret SS' and the associated ciphertext CT
using the KEM encapsulation function and the recipient's public
key recipPubKey.
Derive a final shared secret SS of length SSLen bytes from
the initial shared secret SS' using the underlying key derivation
function:
TBD: Discuss use of JOSE/COSE context specific data.In Direct Key Agreement mode, the output of the KDF MUST be a key of the same length as that used by encryption algorithm. In Key Agreement with Key Wrapping mode, the output of the KDF MUST be a key of the length needed for the specified key wrap algorithm.When Direct Key Agreement is employed, SS is the CEK. When Key Agreement with Key Wrapping is employed, SS is used to wrap the CEK.PQ-KEM DecapsulationThe decapsulation process is as follows:
Decapsulate the ciphertext CT using the KEM decapsulation
function and the recipient's private key to retrieve the initial shared
secret SS':
Derive the final shared secret SS of length SSLen bytes from
the inital secret SS' using the underlying key derivation
function:
KDFKMAC128 and KMAC256 are KMAC-based KDFs specified in this document. KMAC128 and KMAC256 are specified in .KMAC#(K, X, L, S) takes the following parameters:
K: the input key-derivation key. In this document this is the shared secret outputted from the kemEncaps() or kemDecaps() functions.
X: the context. In case of JOSE, it will carry the JOSE context specific data defined in Section 4.6.2 of . In case of COSE, it will carry the COSE context structure defined in Section 5.2 of .
L: the output length, in bits.
S: the optional customization label. In this document this parameter is unused, that is it is the zero-length string "".
Post-quantum KEM in JOSEAs explained in JWA defines two ways to use public key cryptography with JWE:
Direct Key Agreement
Key Agreement with Key Wrapping
This specification describes these two modes of use for PQ-KEM in JWE. Unless otherwise stated, no changes to the procedures described in have been made.Direct Key Agreement
The "alg" header parameter MUST be a PQ-KEM algorithm chosen from the JSON Web Signature and Encryption Algorithms registry defined in .
The CEK will be generated using the process explained in . The output of the MUST be a secret key of the same length as that used by the "enc" algorithm. Both header parameters, "alg" and "enc", MUST be placed in the JWE Protected Header. Subsequently, the plaintext will be encrypted using the CEK, as detailed in Step 15 of Section 5.1 of .
The parameter "kem-ct" MUST include the output ('ct') from the PQ-KEM algorithm, encoded using base64url.
The recipient MUST base64url decode the ciphertext from the "kem-ct" and then use it to derive the CEK using the process defined in . The ciphertext sizes of ML-KEMs are discussed in Section 12 of .
The JWE Encrypted Key MUST be absent.
Key Agreement with Key Wrapping
The derived key is generated using the process explained in and used to encrypt the CEK.
The parameter "kem-ct" MUST include the output ('ct') from the PQ-KEM algorithm, encoded using base64url.
The JWE Encrypted Key MUST include the base64url-encoded encrypted CEK.
The 'enc' (Encryption Algorithm) header parameter MUST specify a content encryption algorithm from the JSON Web Signature and Encryption Algorithms registry, as defined in .
The recipient MUST base64url decode the ciphertext from "kem-ct". Subsequently, it is used to derive the key, through the process defined in . The derived key will then be used to decrypt the CEK.
Post-Quantum KEM in COSEThis specification supports two uses of PQ-KEM in COSE, namely
PQ-KEM in a single recipient setup. This use case utilizes a one
layer COSE structure.
PQ-KEM in a multiple recipient setup. This use case requires a two
layer COSE structure.
Single Recipient / One Layer StructureWith the one layer structure the information carried inside the
COSE_recipient structure is embedded inside the COSE_Encrypt0.The CEK will be generated using the process explained in .
Subsequently, the plaintext will be encrypted using the CEK. The resulting
ciphertext is either included in the COSE_Encrypt0 or is detached. If a payload is
transported separately then it is called "detached content". A nil CBOR
object is placed in the location of the ciphertext. See Section 5
of for a description of detached payloads.The sender MUST set the alg parameter in the protected header, which
indicates the use of PQ-KEM.Although the use of the 'kid' parameter in COSE_Encrypt0 is
discouraged by , this documents RECOMMENDS the use of the 'kid' parameter
(or other parameters) to explicitly identify the recipient public key
used by the sender. If the COSE_Encrypt0 contains the 'kid' then the recipient may
use it to select the appropriate private key.Multiple Recipients / Two Layer StructureWith the two layer structure the PQ-KEM information is conveyed in the COSE_recipient
structure, i.e. one COSE_recipient structure per recipient.In this approach the following layers are involved:
Layer 0 (corresponding to the COSE_Encrypt structure) contains the content (plaintext)
encrypted with the CEK. This ciphertext may be detached, and if not detached, then
it is included in the COSE_Encrypt structure.
Layer 1 (corresponding to a recipient structure) contains parameters needed for
PQ-KEM to generate a shared secret used to encrypt the CEK. This layer conveys
the output ('ct') from the PQ KEM Encaps algorithm in the 'ek' header
parameter (Section 7.2 of ) and encrypted CEK in the encCEK structure
(Section 3.1.2 of ). The unprotected header MAY contain the kid
parameter to identify the static recipient public key the sender has been using with PQ-KEM.
This two-layer structure is used to encrypt content that can also be shared with
multiple parties at the expense of a single additional encryption operation.
As stated above, the specification uses a CEK to encrypt the content at layer 0.JOSE Ciphersuite RegistrationThis specification registers a number of PQ-KEM algorithms for use with JOSE.All security levels of ML-KEM internally utilize SHA3-256, SHA3-512, SHAKE128, and SHAKE256. This internal usage influences the selection of the KMAC128 or KMAC256 Key Derivation Function (KDF) as described in this document.ML-KEM-512 MUST be used with a KDF capable of outputting a key with at least 128 bits of security and with a key wrapping algorithm with a key length of at least 128 bits.ML-KEM-768 MUST be used with a KDF capable of outputting a key with at least 192 bits of security and with a key wrapping algorithm with a key length of at least 192 bits.ML-KEM-1024 MUST be used with a KDF capable of outputting a key with at least 256 bits of security and with a key wrapping algorithm with a key length of at least 256 bits.For readability the algorithm ciphersuites labels are built according to the following scheme:-
]]>
In Direct key agreement, the parameter "alg" MUST be specified, and its value MUST be one of the values specified in . (Note that future specifications MAY extend the list of algorithms.)
In Key Agreement with Key Wrapping, the parameter "alg" MUST be specified, and its value MUST be one of the values specified in the table .
COSE Ciphersuite Registration maps the JOSE algorithm names to the COSE algorithm values (for the PQ-KEM ciphersuites defined by this document).Security ConsiderationsPQC 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.IANA ConsiderationsJOSEThe following has to be added to the "JSON Web Key Parameters" registry:
Parameter Name: "kem-ct"
Parameter Description: PQC KEM ciphertext
Parameter Information Class: Public
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Documents(s): TODO
The following entries are added to the "JSON Web Signature and Encryption Algorithms" registry:
Algorithm Name: MLKEM512-KMAC128
Algorithm Description: PQ-KEM that uses ML-KEM-512 PQ-KEM and the KMAC128 KDF.
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: MLKEM768-KMAC256
Algorithm Description: PQ-KEM that uses ML-KEM-768 PQ-KEM and the KMAC256 KDF.
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: MLKEM1024-KMAC256
Algorithm Description: PQ-KEM that uses ML-KEM-1024 PQ-KEM and the KMAC256 KDF.
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: MLKEM512-KMAC128+A128KW
Algorithm Description: PQ-KEM that uses ML-KEM-512 PQ-KEM, the KMAC128 KDF and CEK wrapped with "A128KW".
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: MLKEM768-KMAC256+A256KW
Algorithm Description: PQ-KEM that uses ML-KEM-768, the KMAC256 KDF and CEK wrapped with "A256KW".
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: MLKEM1024-KMAC256+A256KW
Algorithm Description: PQ-KEM that uses ML-KEM-1024, the KMAC256 KDF and CEK wrapped with "A256KW".
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IANA
Specification Document(s): [[TBD: This RFC]]
Algorithm Analysis Documents(s): TODO
COSEThe following has to be added to the "COSE Algorithms" registry:
Name: MLKEM512-KMAC128
Value: TBD1
Description: PQ-KEM that uses ML-KEM-512 PQ-KEM and the KMAC128 KDF.
Capabilities: [kty]
Change Controller: IANA
Reference: This document (TBD)
Recommended: No
Name: MLKEM768-KMAC256
Value: TBD2
Description: PQ-KEM that uses ML-KEM-768 PQ-KEM and the KMAC256 KDF.
Capabilities: [kty]
Change Controller: IANA
Reference: This document (TBD)
Recommended: No
Name: MLKEM1024-KMAC256
Value: TBD3
Description: PQ-KEM that uses ML-KEM-1024 PQ-KEM and the KMAC256 KDF.
Capabilities: [kty]
Change Controller: IANA
Reference: This document (TBD)
Recommended: No
Name: MLKEM512-KMAC128+A128KW
Value: TBD4
Description: PQ-KEM that uses ML-KEM-512 PQ-KEM, the KMAC128 KDF and CEK wrapped with "A128KW".
Capabilities: [kty]
Change Controller: IANA
Reference: This document (TBD)
Recommended: No
Name: MLKEM768-KMAC256+A256KW
Value: TBD5
Description: PQ-KEM that uses ML-KEM-768, the KMAC256 KDF and CEK wrapped with "A256KW".
Capabilities: [kty]
Change Controller: IANA
Reference: This document (TBD)
Recommended: No
Name: MLKEM1024-KMAC256+A256KW
Value: TBD6
Description: PQ-KEM that uses ML-KEM-1024, the KMAC256 KDF and CEK wrapped with "A256KW".
Capabilities: [kty]
Change Controller: IANA
Reference: This document (TBD)
Recommended: No
AcknowledgmentsThanks to Ilari Liusvaara, Neil Madden and AJITOMI Daisuke for the discussion and comments.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn 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 WordsRFC 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.JSON Web Encryption (JWE)JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.JSON Web Signature and Encryption AlgorithmsIANAn.d.CBOR Object Signing and Encryption (COSE): Initial AlgorithmsConcise 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 a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).This document, along with RFC 9052, obsoletes RFC 8152.Informative ReferencesPQC - API notesSecure Integration of Asymmetric and Symmetric Encryption SchemesA Modular Analysis of the Fujisaki-Okamoto TransformationModule-Lattice-based Key-Encapsulation Mechanism StandardSHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHashTerminology for Post-Quantum Traditional Hybrid SchemesUK 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.
Fundamental Elliptic Curve Cryptography AlgorithmsThis 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 Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)This document defines how to use the Diffie-Hellman 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 ProcessConcise 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.JSON Web Algorithms (JWA)This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.Hybrid key exchange in TLS 1.3University of WaterlooCisco SystemsUniversity of Haifa 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.
*** BROKEN REFERENCE ***Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)TransmuteSecurity Theory LLC This specification defines hybrid public-key encryption (HPKE) for
use with CBOR Object Signing and Encryption (COSE). HPKE offers a
variant of public-key encryption of arbitrary-sized 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 COSE-native security mechanisms or by one
of the authenticated variants of HPKE.
This document defines the use of the HPKE with COSE.
Kyber Post-Quantum KEMMPI-SP & Radboud UniversityCloudflare 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.
Post-Quantum Cryptography for EngineersNokiaNokiaNokiaDigiCert The presence of a Cryptographically Relevant Quantum Computer (CRQC)
would render state-of-the-art, traditional public-key algorithms
deployed today obsolete, since the assumptions about the
intractability of the mathematical problems for these algorithms that
offer confident levels of security today no longer apply in the
presence of a CRQC. This means there is a requirement to update
protocols and infrastructure to use post-quantum algorithms, which
are public-key algorithms designed to be secure against CRQCs as well
as classical computers. These new public-key algorithms behave
similarly to previous public key algorithms, however the intractable
mathematical problems have been carefully chosen so they are hard for
CRQCs as well as classical computers. This document explains why
engineers need to be aware of and understand post-quantum
cryptography. It emphasizes the potential impact of CRQCs on current
cryptographic systems and the need to transition to post-quantum
algorithms to ensure long-term security. The most important thing to
understand is that this transition is not like previous transitions
from DES to AES or from SHA-1 to SHA-2. While drop-in replacement
may be possible in some cases, others will require protocol re-design
to accommodate significant differences in behavior between the new
post-quantum algorithms and the classical algorithms that they are
replacing.