]> China Mobile

BeiJing China chenmeiling@chinamobile.com

China Mobile

BeiJing China suli@chinamobile.com

Huawei Int. Pte Ltd

Singapore Singapore wang.guilin@huawei.com

Security lamps Internet-Draft keyword2 FrodoKEM is a quantum-resistant key encapsulation mechanism (KEM) based on the standard Learning With Errors (LWE) problem，standardized by ISO. FrodoKEM offers multiple parameter sets, with the recommended sets for general use including (e)FrodoKEM-976-AES and (e)FrodoKEM-976-SHAKE for security level 3, and (e)FrodoKEM-1344-AES and (e)FrodoKEM-1344-SHAKE for security level 5. This document specifies the conventions for using FrodoKEM in the Cryptographic Message Syntax (CMS), using the KEMRecipientInfo structure defined in "Use of Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" .

Notes of Change Changes made in version draft-chen-lamps-cms-frodokem-01:

• Update the references with two individual drafts of CFRG.
• Change the citation of FrodoKem from I-D.LBES25 to ISO18033-2-AMD2.

Introduction FrodoKEM is one of three KEMs in the process of ISO standardization [FrodoKEM]. Its security is based on a well-studied hard problem in unstructured lattices, called the learning with errors problem. There are Internet drafts on the algorithm specification of FrodoKEM and how to securely use it . FrodoKEM has both AES and SHAKE variants to offer optimized performance across different hardware platforms. AES variants are highly suitable for devices with hardware acceleration for AES (like AES-NI on Intel processors). SHAKE variants provide competitive or better performance on platforms lacking AES hardware acceleration (such as many embedded systems and general-purpose CPUs). To cover both scenarios, this specification SHALL include both variants. defines the KEMRecipientInfo structure for the use of KEM algorithms in the CMS enveloped-data, authenticated-data, and authenticated-enveloped-data content types. This document specifies the conventions for the direct use of eight recommended FrodoKEM parameter sets within the KEMRecipientInfo structure: (e)FrodoKEM-976-AES, (e)FrodoKEM-976-SHAKE, (e)FrodoKEM-1344-AES and (e)FrodoKEM-1344-SHAKE.

Terminology 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 RFC2119.

FrodoKEM FrodoKEM is one of three KEMs in the process of ISO standardization [FrodoKEM]. Its security is based on a well-studied hard problem in unstructured lattices, called the learning with errors problem. In total, FrodoKEM [FrodoKEM] has 12 variants. Namely, it offers 3 NIST security levels 1, 3, and 5; the pseudorandom generator (PRG) uses AES128 or SHAKE 128; and the KEM public key can be a long-term key (standard mode) or a short-term key (ephemeral mode). According to the current standardization progress in ISO, FrodoKEM will be standardized for only 8 variants for NIST security levels 3 and 5. Namely, there are (e)FrodoKEM-976 and (e)FrodoKEM-1344, but not (e)FrodoKEM-640 for security level 1. To align with ISO, this specification specifies the use of (e)FrodoKEM varaints for security levels 3 and 5 only, not variants for security level 1. Based on the above, this document specifies only eight variants of (e)FrodoKEM for Cryptographic Message Syntax. Namely, (e)FrodoKEM-976-AES and (e)FrodoKEM-976-SHAKE for security level 3, and (e)FrodoKEM-1344-AES and (e)FrodoKEM-1344-SHAKE for security level 5. Key encapsulation mechanism (KEM) is a kind of key exchange, which allows one entity to encapsulate a secret under a (long-term or ephemeral) public key of another entity. By following the definition given in [W-D.K25], a KEM consists of three algorithms:

• KeyGen(k) -> (pk, sk): A probabilistic key generation algorithm, which generates a public encapsulation key pk and a secret decapsulation key sk, when a security parameter k is given.
• Encaps(pk) -> (ct, ss): A probabilistic encapsulation algorithm, which takes as input a public encapsulation key pk and outputs a ciphertext ct and a shared secret ss.
• Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret ss.

FrodoKEM comes in several parameter sets, each designed to meet one of the NIST Post-Quantum Cryptography (PQC) security levels. Here is a table summarizing the key sizes for the main variants of FrodoKEM.

Use of the FrodoKEM Algorithm in the CMS The FrodoKEM algorithm MAY be used for one or more recipients in the CMS enveloped-data content type , the CMS authenticated-data content type , or the CMS authenticated-enveloped-data content type [RFC5083]. In each case, the KEMRecipientInfo structure is used with the FrodoKEM algorithm to securely transport a content-encryption key from an originator to a recipient. The steps for processing FrodoKEM with KEMRecipientInfo follow Section 2 of . To support the FrodoKEM algorithm, a CMS originator MUST implement the Encapsulate() function, and a CMS recipient MUST implement the Decapsulate() function.

RecipientInfo Conventions When the FrodoKEM algorithm is used for a recipient, the RecipientInfo choice for that recipient MUST be the OtherRecipientInfo choice using the KEMRecipientInfo structure defined in . The fields of KEMRecipientInfo have the following meanings:

• version is the syntax version number; it MUST be 0.
• rid identifies the recipient's certificate or public key.
• kem identifies the KEM algorithm; it MUST contain one of id-kem-frodokem976-shake, id-kem-frodokem1344-shake, id-kem-efrodokem976-shake, id-kem-efrodokem1344-shake, id-kem-frodokem976-aes, id-kem-frodokem1344-aes, id-kem-efrodokem976-aes or id-kem-efrodokem1344-aes. These identifiers are reproduced in Section 3.
• kemct is the ciphertext generated for this recipient.
• kdf identifies the key derivation algorithm. Implementations MUST support the HKDF with SHA-256 [FIPS180] using the id-alg-hkdf-with-sha256 KDF object identifier . As specified in , when this object identifier appears in an ASN.1 type AlgorithmIdentifier, the parameters field MUST be absent. Implementations MAY support other KDFs.
• kekLength is the size of the key-encryption key in octets.
• ukm is an optional input to the key derivation function. The secure use of FrodoKEM in the CMS does not depend upon the use of the ukm value, and therefore this document has no requirements for this value. See Section 3 of for more information on the ukm parameter.
• wrap identifies the key-encryption algorithm used to encrypt the content-encryption key.
  • Implementations supporting FrodoKEM-976-AES or FrodoKEM-976-SHAKE MUST support the AES-Wrap-192 Key Wrap algorithm , using the id-aes192-wrap key-encryption algorithm object identifier .
  • Implementations supporting FrodoKEM-1344-AES or FrodoKEM-1344-SHAKE MUST support the AES-Wrap-256 Key Wrap algorithm , using the id-aes256-wrap key-encryption algorithm object identifier .
  • Implementations MAY support other key-encryption algorithms.

Underlying Components When FrodoKEM is used in CMS, the underlying components used in the KEMRecipientInfo structure SHOULD be consistent with the desired minimum security level. To meet the requirements for the KDF and key-wrap algorithm from Section 7 of , the table below provides the minimum requirements for the components used with FrodoKEM.

Use of the HKDF-based Key Derivation Function The HKDF function is a composition of the HKDF-Extract and HKDF- Expand functions. HKDF(salt, IKM, info, L) = HKDF-Expand(HKDF-Extract(salt, IKM), info, L) When used with KEMRecipientInfo, the salt parameter is unused, that is it is the zero-length string "". The IKM, info and L parameters correspond to the same KDF inputs from Section 5 of . The info parameter is independently generated by the originator and recipient. Implementations MUST confirm that L is consistent with the key size of the key-encryption algorithm.

Certificate Conventions specifies the profile for X.509 certificates used in Internet applications. FrodoKEM requires a static public key for the recipient, which the originator obtains from the recipient's certificate. The conventions for carrying a FrodoKEM public key are specified in [I-D.draft-smyslov-lamps-frodokem-certificates].

SMIME Capabilities Attribute Conventions Section 2.5.2 of defines the SMIMECapabilities attribute for advertising a partial list of algorithms that an S/MIME implementation can support. When constructing a CMS SignedData content type , a compliant implementation MAY include the SMIMECapabilities attribute to announce support for one or more of the FrodoKEM algorithm identifiers. The SMIMECapability SEQUENCE representing a FrodoKEM algorithm MUST contain one of the FrodoKEM object identifiers in the capabilityID field. When one of the FrodoKEM object identifiers appears in the capabilityID field, the parameters MUST NOT be present.

Identifiers The identifiers for indicating the use of FrodoKEM in the CMS are defined in [CSOR] and . For convenience, they are reproduced here. frodokem OBJECT IDENTIFIER ::= { iso(1) standard(0) encryption-algorithms(18033) part2(2) key-encapsulation-mechanism(2) 7 } id-alg-hkdf-with-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 28 } aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } id-shake256 OBJECT IDENTIFIER ::= { hashAlgs 12 } id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 } id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }

Security Considerations The security considerations sections of [I-D.draft-smyslov-lamps-frodokem-certificates] and apply to this specification as well. Implementations MUST protect the FrodoKEM private key, the key-encryption key, the content-encryption key, the message-authentication key, and the content-authentication-encryption key. Of these keys, all but the private key are ephemeral and MUST be erased after use. Compromise of the FrodoKEM private key can lead to the compromise of all messages protected with that key. The generation of the private key and the FrodoKEM encapsulation function depend on random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate these values can result in little or no security. Generation of high-quality random numbers is difficult; see [FRODO-SPEC] for more information. The encapsulation and decapsulation of FrodoKEM only output the shared secret and the ciphertext. Implementations MUST NOT use the intermediate values directly for any purpose. Implementations SHOULD NOT leak information about the intermediate values or computations through timing or other "side channels", as an attacker may be able to determine information about keying data and/or the recipient's private key. In general, it is good cryptographic practice to use a given FrodoKEM key pair in only one scheme. This practice avoids the risk that a vulnerability in one scheme could compromise the security of the other.

IANA Considerations TBD

Acknowledgements This document borrows heavily from draft-ietf-lamps-cms-kyber-13, [RFC9690], and the original FrodoKEM specification [FRODO-SPEC]. Thanks go to the authors of those documents.

References Normative References 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. The purpose of this document is to make the AES Key Wrap algorithm conveniently available to the Internet community. The United States of America has adopted AES as the new encryption standard. The AES Key Wrap algorithm will probably be adopted by the USA for encryption of AES keys. The authors took most of the text in this document from the draft AES Key Wrap posted by NIST. This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. 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. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652. ISO n.d. Informative References Microsoft NXP Semiconductors Federal Office for Information Security University of Waterloo This internet draft specifies FrodoKEM, an IND-CCA2 secure Key Encapsulation Mechanism (KEM). About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-longa-cfrg-frodokem/. Source for this draft and an issue tracker can be found at github.com/dstebila/frodokem-internet-draft. Microsoft NXP Semiconductors Federal Office for Information Security University of Waterloo ISO standardized FrodoKEM in June 2026 [ISO18033-2-AMD2]. This document provides security guidance for FrodoKEM for use in protocols. It explains what security claims protocol designers may rely on, what assumptions and conditions are required, what parameter sets are in scope, and what implementors need to do to use FrodoKEM safely. The scope follows the current FrodoKEM Internet-Draft [I-D.FrodoKEM].