Use of FrodoKEM in the Cryptographic Message Syntax

Introduction FrodoKEM is one of three KEMs in the process of ISO standardization . Its security is based on a well-studied hard problem in unstructured lattices, called the learning with errors problem. The algorithm details of FrodoKEM are specified in . 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 include both variants. "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" 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 variants of FrodoKEM in the CMS with the KEMRecipientInfo structure: (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. Note that these are all variants of FrodoKEM to be standardized in ISO.

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 In total, 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 the 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. 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.

Table 1 summarizes the sizes of keys, ciphertext, and shared secret for all variants of FrodoKEM with security levels 3 and 5. Note that using either AES128 or SHAKE 128 does not affect these sizes.

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 one ore multiple recipients. 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 .

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 and . For convenience, they are reproduced here. frodokem OBJECT IDENTIFIER ::= { iso(1) standard(0) encryption-algorithms(18033) part2(2) key-encapsulation-mechanism(2) 7 }

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 , , and the FrodoKEM specification . Thanks go to the authors of those documents.