NIST SP 800-227 日本語訳

Gorjan Alagic Elaine Barker Lily Chen Dustin Moody Angela Robinson Hamilton Silberg Noah Waller

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-227

Gorjan Alagic Elaine Barker Lily Chen Dustin Moody Angela Robinson Hamilton Silberg Noah Waller

Computer Security Division Information Technology Laboratory

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-227

September 2025

U.S. Department of Commerce Howard Lutnick, Secretary

National Institute of Standards and Technology

Craig Burkhardt, Acting Under Secretary for Standards and Technology and Acting NIST Director

Certain commercial equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax

Publication History Approved by the NIST Editorial Review Board on 2025-09-03

How to cite this NIST Technical Series Publication: Alagic G, Barker EB, Chen L, Moody D, Robinson A, Silberg H, Waller N (2025) Recommendations for Key-Encapsulation Mechanisms. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-227. https://doi.org/10.6028/NIST.SP.800-227

Gorjan Alagic: 0000-0002-0107-6037

Elaine Barker: 0000-0003-0454-0461

Lily Chen: 0000-0003-2726-4279

Dustin Moody: 0000-0002-4868-6684

Angela Robinson: 0000-0002-1209-0379

Hamilton Silberg: 0009-0004-4178-8954

Noah Waller: 0000-0002-6979-9725

sp800-227-comments@nist.gov

Additional Information Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/227/final, including related content, potential updates, and document history.

All comments are subject to release under the Freedom of Information Act (FOIA).

A key-encapsulation mechanism (KEM) is a set of algorithms that can be used by two parties under certain conditions to securely establish a shared secret key over a public channel. A shared secret key that is established using a KEM can then be used with symmetric-key cryptographic algorithms to perform essential tasks in secure communications, such as encryption and authentication. This document describes the basic definitions, properties, and applications of KEMs. It also provides recommendations for implementing and using KEMs in a secure manner.

cryptography; encryption; key-encapsulation mechanism; key establishment; public-key cryptography.

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

Patent Disclosure Notice

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringe-ment in the use of this publication.

A key-establishment scheme is a set of algorithms that can be used to securely establish a shared secret key between two or more parties. Such a shared secret key can then be used to perform tasks that are suitable for symmetric-key cryptography, such as efficient confidential communication.

Many widely deployed key-establishment schemes — including those specified in NIST Spe-cial Publication (SP) 800-56A [1] and SP 800-56B [2] — are vulnerable to cryptographic at-tacks that make use of a large-scale, cryptanalytically relevant quantum computer. In 2016, NIST initiated a process to select and standardize a set of post-quantum key-establishment schemes (i.e., key-establishment schemes that would not be vulnerable to attacks even by cryptanalytically-relevant quantum computers). In response, NIST received feedback from the cryptographic community that the post-quantum key-establishment schemes best suited for standardization and widespread deployment are key-encapsulation mecha-nisms (KEMs). The first KEM standard that resulted from this NIST Post-Quantum Cryptog-raphy (PQC) standardization process was ML-KEM, which is specified in Federal Information Processing Standards (FIPS) publication 203 [3].

At the time of the standardization of ML-KEM, NIST had not provided extensive guidelines on the basic definitions, properties, and applications of KEMs. This recommendation is meant to provide these guidelines, supplement the current and future standardization of KEMs, and provide recommendations for implementing and using KEMs in a secure man-ner.

This recommendation provides guidelines on the basic definitions, properties, and appli-cations of KEMs; supplements the current and future standardization of KEMs; and makes some requirements and recommendations for implementing and using KEMs in FIPS 140-validated cryptographic modules. This recommendation also provides guidelines for ven-dors who wish to securely combine keying material produced via approved post-quantum methods with keying material produced via other (potentially quantum-vulnerable) meth-ods.

This recommendation does not discuss how or when to migrate from quantum-vulnerable key-establishment procedures to post-quantum KEMs (see [4]), nor does it provide a spec-ification for any particular KEM. Such specifications will be provided in a FIPS or an SP, such as the specification of ML-KEM in FIPS 203 [3].

This recommendation includes explanatory and educational material to aid in the general understanding of KEMs. While SPs typically only include material that pertains to what is approved, this SP describes KEMs both generally and with respect to what is approved. Specific requirements will be clearly noted with “shall” and “must” statements.

Conforming implementations of approved KEMs are required to satisfy all of the requirements below. Requirements that are testable by a Cryptographic Module Validation Program (CMVP) validation lab are enumerated with the prefix “RS,” and requirements that are not testable by a validation lab are enumerated with the prefix “RM.” Each requirement is directly quoted from the corresponding referenced section. Requirements RS6, RS7, RS8, RS10, and RS11 pertain to key confirmation (Sec. 4.4), which is recommended but not required.

The following requirements are testable by a CMVP validation lab (i.e., shall statements):

RS3 (Section 3.1) KEM implementations shall use approved components with security strengths that meet or exceed the required strength for each KEM parameter set.

RS5 (Section 3.2) Except for random seeds and data that can be easily computed from public information, all intermediate values used in any given KEM algorithm (i.e., KeyGen, Encaps, and Decaps) shall be destroyed before the algorithm terminates.

RS6 (Section 4.2) If an application uses an ephemeral key pair, the key pair shall be used for only one execution of key-establishment via a KEM and shall be destroyed as soon as possible after its use.

RS9 (Section 4.4.2) The key-confirmation key shall only be used for key confirmation and destroyed after use.

RS10 (Appendix C.1) When key confirmation requires the use of a MAC algorithm, it shall be an approved MAC algorithm (e.g., HMAC, AES-CMAC, KMAC). In addition, AES-GMAC (specified in [9]) is an approved MAC algorithm and may be used.

The following requirements are not testable by a CMVP validation lab (i.e., must state-ments):

RM1 (Section 3.1). Implementations must correctly implement the mathematical functionality of the target KEM. ²

RM2 (Section 4.2) In applications of KEMs, a parameter set with an application-appropriate security strength must be selected (see [10, Section 2.2]).

RM3 (Section 4.2) If an encapsulating party obtains the static encapsulation key of another party, it must have assurance of the other party’s ownership of the key before or during the execution of key-establishment.

RM4 (Section 4.2) The devices used to execute KEM algorithms and store any sensitive data (e.g., decapsulation keys) must be appropriately secured.

RM5 (Section 4.2) The key-establishment process that takes place over the channel used by Alice and Bob must satisfy an application-appropriate notion of integrity.

This section provides a high-level overview of KEMs, which are collections of mathematical functions (some of which include random inputs) and data that specify parameters. Section 3 describes how to implement a KEM as a collection of computer programs, and Sec. 4 describes how to deploy KEMs in applications.

Modern symmetric-key cryptography provides a wide range of useful functionalities, including secure and highly efficient computation and communication. Before symmetric-key cryptography can be used, the participating parties need to establish a shared secret (i.e., symmetric) key. One approach to establishing such a key is over a public communication channel. Any algorithmic method that establishes a shared secret key over a public channel is called a key-establishment scheme. A general key-establishment scheme can require multiple rounds of communication and involve any number of parties.

A KEM is a specific type of key-establishment scheme. Typical key establishment via a KEM involves two parties (here referred to as Alice and Bob) and consists of the following three stages (see Fig. 1):

Security of KEMs. When a KEM is used as in Fig. 1, the result should be a shared secret key that is random, unknown to adversaries, and identical for Alice and Bob with high probability. Ensuring that security holds in practice is a complex task that relies on three conditions:

Each of these three conditions is essential for security. For example, a KEM that is theoretically secure (i.e., satisfies condition 1) but is implemented without side-channel countermeasures (i.e., does not satisfy condition 2) or is deployed on a device with physical vulnerabilities (i.e., does not satisfy condition 3) is likely to be insecure in practice.

Fig. 1. Outline of key establishment using a KEM

History and development. KEMs were first introduced by Cramer and Shoup [11, 12] as a building block for constructing highly efficient public-key encryption (PKE) schemes. Their approach combines a KEM with a data encryption mechanism (DEM), which is simply a symmetric-key encryption scheme. The KEM is used to generate a shared secret key, while the DEM is used to encrypt an arbitrarily long stream of messages under that key. This is commonly referred to as the KEM/DEM paradigm (see the HPKE example in Sec. 5.2.1). This approach to constructing highly efficient public-key encryption has been the subject of several standards [1, 2, 11, 13–16]. Most recently, KEMs have attracted significant attention due to most of the post-quantum key-establishment candidates in the NIST PQC standardization process being KEMs. This ongoing process has produced one KEM standard so far — ML-KEM in FIPS 203 [3] — with more KEM standards likely to follow.

This section establishes the basic definitions and properties of KEMs. Note that probabilistic algorithms require randomness, while deterministic algorithms do not.

In general, Definition 1 only requires some very basic properties from the four components that make up a KEM (see Example 1 below). In order to be useful and secure, a KEM should fulfill a number of additional properties. The first such property is correctness of the KEM algorithm. Correctness ensures that, in an ideal setting, the process in Fig. 1 almost always produces the same shared secret key value for both parties.

The following two simple but instructive examples show abstract KEMs that satisfy Defini-tion 1 and Definition 2.

Example 1: Simple but insecure. As the following example shows, a correct and efficient KEM can still be completely insecure. Define a KEM DONOTUSE as follows:

KEM examples. Section 5.1 briefly discusses three additional examples of KEMs:

ECDH-KEM and RSASVE-KEM are based on NIST-standardized key-establishment schemes that can easily be viewed as KEMs. ML-KEM is the first key-establishment scheme to be standardized by NIST directly as a KEM.

A remark on key transport and key agreement. There are various ways to categorize two-party key-establishment schemes. One particular categorization distinguishes between key agreement and key transport. In key agreement (e.g., a Diffie-Hellman key exchange), both parties contribute information that influences the final shared secret key so that neither party can predetermine it. In key transport (e.g., RSA-OAEP [2]), one party selects the key and then transmits it (in some form) to the other party.

This section discusses the theoretical security of KEMs. Section 3 discusses KEM imple-mentation security, and Sec. 4.2 discusses the secure deployment of KEMs.

Challenger:

Adversary:

Challenger:

Adversary:

Active adversaries and IND-CCA. Real-world experience indicates that adversaries can sometimes actively interfere with key-establishment processes and use this ability to un-cover the shared secret key. For example, an active adversary may be able to convince an honest user to decapsulate some ciphertexts of the adversary’s choosing. In such a sce-nario, it is natural to ask whether other ciphertexts are still protected. In this setting, IND-CPA security is insufficient. Instead, one must consider security against so-called chosen-ciphertext attacks (CCA)³ [17].

ML-KEM, the first post-quantum KEM standardized by NIST, is believed to satisfy IND-CCA security [3].

As discussed in Sec. 2.1, a KEM (as a mathematical object) should satisfy both correctness (Definition 2) and an appropriate notion of security (Definition 3 or Definition 4). In order for such a KEM to be used in real-world applications, it needs to be implemented in actual code as part of a cryptographic module. The quality of the resulting implementation has a dramatic impact on usability and security in real-world applications.

The following subsections detail requirements for cryptographic modules that implement approved KEMs. However, adherence to these requirements does not guarantee that a given implementation will be secure. For a discussion of requirements for applications that make use of a KEM cryptographic module, see Sec. 4.2.

Conforming implementations of approved KEMs are required to comply with the require-ments outlined in this section as well as all other applicable NIST standards. In addition, such implementations are required to use only approved cryptographic elements and pass FIPS-140 validation.

Implementing according to NIST standards. Implementations shall comply with a specific NIST FIPS or SP that specifies the algorithms of the relevant KEM. For example, a conform-ing implementation of ML-KEM shall comply with FIPS 203 [3]. Each FIPS or SP that speci-fies a KEM will have special requirements for the particular scheme in question, including specifications for all algorithms and parameter sets of the relevant KEM. In particular, con-crete data types will be specified for the parameter sets, keys, ciphertexts, and shared secret keys (Definition 1) of the relevant KEM. Assurance of parameter validity is obtained by checking the lists of approved parameters in the appropriate publication.

The requirements in any FIPS or SP that standardizes a particular KEM are in addition to the general requirements described in this section. Any implementations shall follow the guidelines given in FIPS 140-3 [5] and associated implementation guidance.

Approved cryptographic elements. KEMs commonly make use of other cryptographic elements, such as RBGs and hash functions (see Appendix D). Typically, the security of a system consisting of multiple cryptographic elements is at best as secure as the weakest element. When not already specified by the KEM parameter set, KEM implementations shall use approved cryptographic elements with security strengths that meet or exceed the required strength for each KEM parameter set. The security strength of the selected parameter set should be at least the desired security strength of the application. In addition, random bits shall be generated using approved techniques, as described in the latest revisions of SP 800-90A, SP 800-90B, and SP 800-90C [6–8]. For using randomness in key generation, see SP 800-133 [18].

Testing and validation. Mistakes in implementations can easily lead to security vulner-abilities or a loss of usability. Therefore, it is crucial that implementations are validated for conformance to NIST cryptographic standards and FIPS 140 by the Cryptographic Al-gorithm Validation Program (CAVP) and CMVP. Validation testing checks whether a given implementation correctly computes the desired output for only a small number of (often randomly sampled) inputs. This means that validation testing does not guarantee correct functioning on all inputs, which is often impossible to ensure. Nonetheless, implementa-tions must correctly implement the mathematical functionality of the target KEM. As vali-dation only tests input-output behavior, implementations need not follow the exact step-by-step algorithmic specifications in the NIST standard that specifies the relevant KEM. Any implementation that produces the correct output for every input will pass validation.

Requiring equivalence only at the level of input-output functionality (e.g., rather than in terms of step-by-step behavior) is desirable, as different implementations can then be op-timized for different goals. For example, some implementations will focus on maximizing efficiency, while other implementations will employ numerous side-channel and leakage protection techniques.

KEM implementations need to manage all cryptographic data appropriately, including data used during the execution of KEM algorithms (i.e., intermediate values) and data at rest (e.g., decapsulation key). As a cryptographic module has no control over data that exists outside of the module (e.g., while in transit from one module to another), such data is not discussed here. However, a cryptographic module can exert control over what data it outputs to the outside world (e.g., by ensuring correct implementations of all functions). It can also exert control over what data it accepts from the outside world (e.g., by performing appropriate input-checking and importing).

In general, cryptographic data needs to be destroyed as soon as it is no longer needed. Some examples include destroying intermediate computation values at the end of an algo-rithm, destroying the randomness generated by RBGs after encapsulation, and destroying keys after all relevant communication sessions are completed.

Input checking. The correct and secure operation of cryptographic operations depends crucially on the validity of the provided inputs. Even relatively benign faults, such as ac-cepting an input that is too long or too short, can have serious security consequences. KEM implementations need to perform input checking in an appropriate manner for all KEM algorithms (i.e., KeyGen, Encaps, and Decaps). The exact form of the required input checking is described in the FIPS or SP that specifies the relevant KEM.

Sometimes, an input will not need to be checked. Instead, the implementer can acquire assurance that the input was validly generated or has already been checked, as in the fol-lowing cases:

Intermediate values. All intermediate values used in any given KEM algorithm (i.e., KeyGen, Encaps, Decaps) shall be destroyed before the algorithm terminates. However, there are two exceptions to this rule:

When values are stored under either of these exceptions, the storage needs to be per-formed according to the rules for data at rest.

The outputs of a KEM algorithm are not considered to be intermediate values and will thus not be immediately destroyed in typical situations. The format in which outputs and inputs are stored depends on the implementation (see the discussion of data formats below.)

Data at rest. A cryptographic module that implements a KEM needs to maintain certain data at rest. This can include both private data (e.g., seeds, decapsulation keys) and public data (e.g., encapsulation keys). In general, private data needs to be stored within the cryp-tographic module in a manner that is secure against both leakage and unauthorized mod-ification. Private data needs to be destroyed as soon as it is no longer needed. The import and export of private data (e.g., seeds, decapsulation keys, shared secret keys) needs to be performed in a secure manner. In general, public data stored within the cryptographic module needs to be stored in a manner that is secure against unauthorized modification [5, 19].

Data formats, import, and export. FIPS validation tests input and output the behavior of relevant KEM algorithms using a specific data format. Typically, this format is byte arrays that contain the inputs and outputs described in the FIPS or SP that specifies the relevant KEM. This format is required for testing but is not a requirement for internal storage, data import, or data export. A given cryptographic module may choose to store, import, or export data (whether sensitive or not) using other formats. The desired format can vary significantly depending on the application. For example, some applications might call for storing keys using only a short seed, while other applications might call for storing keys in an expanded format that allows for faster computations. In any case, the storage, import, and export of sensitive data needs to be performed securely, regardless of the chosen data format.

The following are additional requirements for cryptographic modules that implement ap-proved KEMs.

Failures and aborts. Any of the KEM algorithms (i.e., KeyGen, Encaps, Decaps) and their cryptographic elements (e.g., DRBGs, hash functions) can potentially fail or abort. This could be a result of normal KEM operations (e.g., decapsulating a ciphertext that was cor-rupted by the environment during transmission), a hardware or software failure (e.g., a failed DRBG execution due to a memory fault), or an adversarial attack. Implementers need to take precautions to ensure that the cryptographic module handles failures and aborts appropriately. In particular, leaking information about failures and aborts outside of the perimeter of the cryptographic module should be avoided.

Side-channel protection. Cryptographic modules for KEMs should be designed with ap-propriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly.

This section describes how to deploy a KEM in real-world applications in a manner that is useful and secure, assuming that the KEM under discussion satisfies an appropriate notion of theoretical security (see Sec. 2.3) and has been securely implemented in a cryptographic module (see Sec. 3).

This section describes how a KEM can be used to establish a shared secret key between two parties. The description will go into greater detail than the brief outline in Sec. 2.1. However, since KEMs are highly flexible and can be used in a wide range of applications and contexts, no single description can account for all variations. Section 5 provides more detailed examples of special cases of key establishment using a KEM.

For simplicity of exposition, the two parties in the key establishment process will be re-ferred to as Alice and Bob. It is assumed that Alice and Bob are communicating over a single bidirectional channel and will only use that channel to transmit data to each other.

Figure 4 depicts the high-level stages of this process. Note that some desirable security properties might not be achieved by a protocol of this form and may require additional steps and ingredients.

Alice:

Bob:

Π,p

1.

←−−−−−−−→

Fig. 4. Simple key establishment using a KEM

Additional considerations. Steps 1-5 in the key-establishment process might need to be modified, depending on the security and functionality needs of the application. Some common modifications are as follows.

Authentication. In most applications, some form of authentication and cryptographic in-tegrity checking is required (e.g., to prevent “machine-in-the-middle” attacks). Assuring this is highly application-dependent and typically requires additional cryptographic ele-ments, such as digital signatures and certificates. Section 5.2.4 and Sec. 5.2.3 provide some illustrative examples.

This section discusses general requirements for securely using approved KEMs in applica-tions. As discussed in point 1 below, the first step involves selecting an approved KEM that has been implemented in a validated cryptographic module (see Section 3). Deploying such a cryptographic module in applications entails a number of additional requirements that are outlined below. Adherence to these requirements does not guarantee that the relevant KEM application will be secure. The overall requirements fall into four general categories: KEM algorithm security, device security, channel security, and key usage secu-rity.

KEM key-pair usage. If an application uses an ephemeral key pair, the key pair shall be used for only one execution of key-establishment via a KEM and shall be de-stroyed as soon as possible after its use.

If an encapsulating party obtains the static encapsulation key of another party, it must have assurance of the other party’s ownership of the key before or during the execution of key-establishment. This assurance can be obtained from a trusted party (e.g., a certificate authority) or a combination of proof of possession (see Sec. 4.5) and verification of real-world identity.

Physical protection. Devices need to be appropriately protected against attacks (see [19, Section 5]). This includes protection against leakage, physical intrusion, remote access, and corruption.

Secure storage. Devices need to provide appropriate secure storage for sensitive data (e.g., KEM keys, seeds, shared secret keys, any derived keys) and destroy that data when required by the cryptographic module (see Sec. 3.2). For further guide-lines on key storage considerations, see SP 800-57pt1 [19] and SP 800-152 [10, Sec-tion 2.2].

Preestablished versus simultaneous. Ensuring the integrity of the key-establishment process could be achieved by first ensuring the integrity of the channel and then performing key establishment. More commonly, integrity is assured simultaneously with key establishment by augmenting the key-establishment process with addi-tional steps and checks (see, e.g., Section 5.2.3).

Unilateral versus bilateral authentication. For some applications, only one of the parties is assured of the other’s identity and the integrity of their messages. This is commonly called a unilaterally authenticated key exchange (see Sec. 5.2.3). In other applications, both Alice and Bob require assurances of the other party’s identity and the integrity of their messages. This is commonly called a bilaterally authenticated key exchange.

Secure authentication algorithms. For all applications, the cryptographic algorithms (e.g., digital signature algorithms) and other elements (e.g., certificates) required to establish channel integrity need to be selected and deployed securely.

Shared-secret-key processing and management. Key-derivation and key-confirmation steps are performed appropriately, as required by the application (see Sec. 4.3 and 4.4). Each shared secret key and any derived keys are destroyed as soon as they are no longer needed (see Sec. 4.2).

Secure symmetric-key algorithms. The KEM shared secret key and any derived keys should only be used with appropriately secure symmetric-key cryptographic algo-rithms. In particular, the security of the symmetric-key algorithms used is appropri-ate for the security provided by the KEM so that the combined algorithm (consisting of key establishment followed by symmetric cryptography operations) fulfills the de-sired security properties.

As specified in SP 800-108 [20], key derivation consists of applying a key-derivation method (KDM) to a key-derivation key. A KDM is an algorithm for transforming a given key-derivation key (possibly with some other data) into keying material (e.g., a list of keys).

When key derivation for a KEM Π is needed, the shared secret key output by Π (i.e., as an output of Π.Encaps or Π.Decaps) may be used as a key-derivation key supplied to an approved key-derivation method specified in SP 800-108 [20], SP 800-56C [21], or SP 800-133 [18]. If a KDM from SP 800-56C is used, the shared secret key of the KEM is used as an input to the KDM in place of the shared secret. A key derivation step is included in the example protocol in Sec. 5.2.3.

Key confirmation (KC) refers to the actions taken to provide assurance to one party (i.e., the key-confirmation recipient) that another party (i.e., the key-confirmation provider) pos-sesses matching keying material. In the case of KEMs, this confirmation is done for keying material that was produced by encapsulation and/or decapsulation.

Key confirmation should be used during KEM usage, as it may enhance the security prop-erties of the overall key-establishment process. Confirming successful establishment of the shared secret key can also address potential errors in transmission or decapsulation. Key confirmation can also act as a proof of possession (see Sec. 4.5). While this section includes a description of an explicit process, key confirmation can be accomplished in a va-riety of other ways. For example, successful use of the shared secret key for authenticated encryption can act as key confirmation.

Key confirmation is typically achieved by exchanging a value that can only be calculated correctly with very high probability if the key establishment was successful. Some com-mon protocols perform key confirmation in a manner that is integrated into the steps of the protocol. For example, bilateral key confirmation is provided during a TLS handshake protocol by the generation and verification of a message authentication code (MAC) over all previous messages in the handshake using a symmetric MAC key that was established during the handshake.

In some circumstances, it may be appropriate to perform key confirmation by including dedicated key-confirmation steps in a key-establishment scheme. An acceptable method for providing key confirmation during a key-establishment scheme involves the KC provider calculating a MAC tag on MAC_Data and sending the MAC tag to the KC recipient for confir-mation of the provider’s correct calculation of the shared secret key. Unilateral key confir-mation is provided when only one of the parties serves as the key-confirmation provider. If mutual key confirmation is desired (i.e., bilateral key confirmation), then the parties swap roles for the second KC process, and the new provider (i.e., the previous recipient) sends a MAC value on a different data string (i.e., different MAC_Data) to the new recipient (i.e., the previous provider).

This recommendation makes no statement as to the adequacy of other methods.

Key-confirmation key. The key-confirmation steps specified in this recommendation can be incorporated into any scheme using a KEM to establish a shared secret key. To perform key confirmation, a dedicated KC key will be determined from the shared secret key pro-duced by the KEM. The KC provider will use the KC key with an approved MAC algorithm to create a MAC tag on certain data and provide the tag to the KC recipient. The KC recipient will then obtain the KC key from their copy of the shared secret key produced by the KEM and use it to verify the MAC tag.

In order to create and validate the MAC tag for the created MAC_Data, the parties cre-ate a dedicated key-confirmation key (KC_Key). This can be either a portion of the KEM shared secret key or part of the keying material derived from the KEM shared secret key when using a derivation function (see Sec. 4.3). The KC_Key shall only be used for key confirmation and destroyed after use. See Appendix C.1 for KC_Key lengths.

The key-confirmation process can be achieved in multiple ways. The following example showcases unilateral key confirmation from the encapsulator to the decapsulator, which can be used for a client (e.g., Alice) requesting confirmation of successful key establishment from a server (e.g., Bob). Figure 5 shows this process. Some desirable security properties might not be achieved by a protocol of this form and may require additional steps and ingredients.

Alice (Decapsulator, Client):

Bob (Encapsulator, Server):

Fig. 5. Key-confirmation example with an ephemeral key pair

A key-pair owner may need to provide proof-of-possession (PoP), which is the assurance that they possess the private decapsulation key corresponding to the public encapsulation key. In practice, PoP for RSA encryption key pairs (i.e., encryption key, decryption key) has historically been provided by reusing the same keys as a digital signature key pair (i.e., verification key, signing key). A key-pair owner can provide assurance that they possess the secret decryption key by signing a message using the private signing/decryption key. The party seeking assurance can verify the signature using the public verification/encryption key. Unfortunately, this shortcut does not necessarily apply to all KEMs, so it is important to consider alternative approaches to providing PoP for KEMs.

Consider the case in which Bob has obtained another party’s static public encapsulation key and is communicating with a party purporting to be the key-pair owner corresponding to that encapsulation key. Bob may seek PoP from the other party before any further engagement. One method to obtain PoP is for Bob to participate in a KEM protocol that includes key confirmation (see Sec. 4.4) and in which assurance of the identity of the other party is provided. This method can be used for both static and ephemeral key pairs.

However, for static key pairs, PoP can also be provided in a certificate by a certificate au-thority (CA). Consider the case in which Alice is the owner of a static KEM key pair and would like to acquire a certificate establishing her ownership. A certificate authority (CA) would require PoP from Alice prior to issuing and publishing a certificate. Bob could then acquire the certificate from either Alice or the CA and would have assurance that Alice pos-sesses the private key. Methods for performing PoP by a CA for KEMs are being developed.

Alice (key pair owner)

Bob (CA)

Fig. 6. KEM PoP between a key-pair owner and CA

Combining multiple key-establishment schemes into a single key-establishment scheme can be advantageous for some applications (e.g., during the migration to post-quantum cryptography). The discussions of such schemes in this document will adhere to the ter-minology established in [23].

A multi-algorithm key-establishment scheme combines shared secret values that are gen-erated using two or more key-establishment schemes. The underlying schemes are called the components of the overall scheme. In general, the multi-algorithm scheme does not need to have the same interface as its components. In this document, for example, multi-algorithm schemes will always be KEMs, while their components need not be.

A well-designed multi-algorithm scheme will be secure if at least one of the component schemes is secure. This may provide some protection against vulnerabilities that are dis-covered in one of the component schemes after deployment. For example, the migra-tion to post-quantum key-establishment techniques might initially include multi-algorithm solutions that combine one new post-quantum algorithm with one tried-and-tested but quantum-vulnerable (or traditional) algorithm. This is sometimes referred to as hybrid post-quantum/traditional (PQ/T) key establishment. For example, X-Wing KEM is a hybrid PQ/T KEM built from two components: ML-KEM (a lattice-based post-quantum KEM) and X25519 (a traditional Diffie-Hellman-style key exchange) [24].

This section outlines approved approaches for multi-algorithm key establishment, which have two stages:

For simplicity, the exposition below focuses on a particular case: constructing a single KEM from two component KEMs. Since both the components and the multi-algorithm scheme in this case are of the same type (i.e., KEMs), the result is called a composite KEM. Most key-establishment schemes of interest can easily be expressed as KEMs (see, e.g., ECDH-KEM in Sec. 5.1.1 and RSA-KEM in Sec. 5.1.2). Moreover, the hybrid PQ/T application typically calls for two component schemes: one post-quantum scheme, and one traditional scheme. The two-algorithm composite KEM described below is easily adapted to other cases, such as combining more than two schemes or combining KEMs with non-KEMs.

Since the inputs to KeyCombine include the composite encapsulation key, the decapsulat-ing party must retain a copy of that key or maintain the ability to recreate it after perform-ing key generation.

General multi-algorithm schemes. The above construction can be extended in the obvi-ous way to composite constructions that use more than two component KEMs. Extend-ing to the case of a completely general multi-algorithm key-establishment scheme can be more complex, as the components in such a scheme can vary widely. For example, such schemes could potentially include pre-shared keys or shared secrets established via quan-tum key distribution. Still, most multi-algorithm schemes will likely include a step in which a series of shared secrets are combined via a key combiner algorithm of a form similar to KeyCombine above. In those cases, an approved key combiner discussed in Sec. 4.6.2 shall be used.

This section describes approved methods for combining shared secrets as part of a multi-algorithm key-establishment scheme. Choosing such a method amounts to selecting a key combiner KeyCombine. At a minimum, KeyCombine accepts two shared secrets as input, where one or both may be shared secret keys. Optionally, KeyCombine can also accept additional information, such as ciphertexts, encapsulation keys, parameter sets, or other context-dependent data (e.g., the composite KEM in Sec. 4.6.1). As output, KeyCombine produces a single shared secret key.

This section describes how cryptographic methods standardized in other NIST publications can be used as key combiners under an appropriate interpretation. There are two cate-gories of such key combiners:

Concatenation of inputs. The following descriptions involve invocations of functions (e.g., hash functions \(H : \{0,1\}^* \to \{0,1\}^n\)) on multiple comma-separated inputs (e.g., \(z := H(x, y)\)). This should be distinguished from invoking the same function on a single input that is formed by simply concatenating those inputs (e.g., \(w := H(x \| y)\)). For example, if the lengths of the two inputs can vary, concatenation can have unintended consequences (e.g., \(x \| y = x' \| y'\) even though \((x, y) \neq (x', y')\)). However, an appropriate encoding of a pair \((x, y)\) as a single bitstring can specify the lengths of \(x\) and \(y\) such that invoking \(H\) on \((x, y)\) is distinct from invoking \(H\) on \((x', y')\).

The interpretation of invoking a function on comma-separated inputs generally depends on the application and encoding and might also involve specifying the lengths of each individual input. In some scenarios, simple concatenation can also be appropriate. In any case, it is important to choose and fix this interpretation in a manner that is appropriate for the given application.

Key combiners derived from SP 800-133. SP 800-133 [18] provides three approved methods for combining cryptographic keys that were generated in an approved way. These methods can be broadly described as concatenation, XORing, and key extraction using HMAC. Some of these methods can also be applied to just a single key. As discussed in Sec. 4.3, these methods are approved for key derivation for approved KEMs.

When combining multiple keys \(K_1, K_2, \ldots, K_t\), the key-combination methods found in SP 800-133 [18] require every key \(K_j\) for \(j \in \{1, 2, \ldots, t\}\) to be generated using approved methods. These methods can be used directly as key combiners for constructing multi-algorithm schemes in cases where all of the component schemes are approved, and each one produces a key. Any protocol using multi-algorithm KEMs with a concatenation key combiner should ensure that the final shared secret key from the key combiner is passed through a KDF before use.

The typical goal of a composite KEM construction is to ensure that security will hold if any of the component KEMs is secure. There are some important security considerations when constructing composite KEMs.

The two main security properties that KEMs can satisfy (see Sec. 2.3) are:

Security in practice. While composite schemes are meant to increase security, they nec-essarily add a layer of additional complexity to the basic KEM framework. This additional complexity will be reflected in implementations and applications and could introduce se-curity vulnerabilities. Moreover, adding composite schemes introduces additional choices in protocols, which could also introduce vulnerabilities (e.g., in the form of “downgrade attacks”). Implementers and users should be aware of the potential challenges in imple-menting and deploying composite schemes.

This section is meant to help readers understand some aspects of how KEMs are con-structed. It only provides examples, not requirements or specific guidelines.

The following subsections discuss three key-encapsulation mechanisms: ECDH-KEM, RSA-KEM, and ML-KEM. While ECDH and RSA key transport are not typically described as KEMs, the discussions below will give a high-level description of how both can be naturally viewed as KEMs. The goal of these descriptions is illustrative only. As FIPS 203 already contains a complete description of ML-KEM, the discussion below will simply reference the relevant parts of FIPS 203 [3].

A KEM may be constructed from a Diffie-Hellman (DH) key-agreement scheme. The high-level idea is that, if the two parties in a DH scheme send their messages in sequential order (e.g., Alice first, then Bob), then:

For example, a KEM can be constructed from the C(1e, 1s, ECC CDH) Scheme from SP 800-56A [1] as follows:

The use of this KEM requires that all assumptions for the scheme specified in SP 800-56A are met and that all necessary assurances have been obtained. This KEM is IND-CPA-secure if the computational Elliptic Curve Diffie Hellman problem is hard for parameter set ParamSets. The computational Elliptic Curve Diffie Hellman problem is efficiently solved by a quantum computer so this KEM is considered to be quantum-vulnerable, as mentioned in Section 2.2. This KEM is not claimed to be IND-CCA-secure. In similar ways, KEMs could be constructed from the C(1e, 1s, FFC DH), C(2e, 0s, ECC CDH), and C(2e, 0s, FFC DH) schemes.

For example, a KEM can be constructed from RSASVE from SP 800-56B [2] as follows:

ML-KEM is a high-performance, general-purpose, lattice-based key-encapsulation mechanism. It is a NIST-approved KEM and was standardized in FIPS 203 [3]. ML-KEM is based on CRYSTALS-Kyber [26], which was a candidate in the NIST PQC standardization process. It is believed to satisfy IND-CCA security (Definition 4), even against adversaries in possession of a cryptanalytically relevant quantum computer [17, 27, 28]. The asymptotic, theoretical security of ML-KEM is based on the presumed hardness of the Module Learning with Errors (MLWE) problem [29, 30].

FIPS 203 directly describes ML-KEM as a KEM in a manner that closely matches the notation of this document. Specifically, the components of ML-KEM are described in FIPS 203 as follows [3]:

This document treats parameter sets as an explicit input for the KEM algorithms KeyGen, Encaps, and Decaps. By contrast, the algorithms of ML-KEM described in FIPS 203 expect the chosen parameter set to be stored in a set of global variables that are accessible to each of the algorithms of ML-KEM. This is only a difference in presentation and does not imply any particular implementation requirement.

This section provides a high-level overview of several example applications of KEMs.

A KEM can be combined with a symmetric-key encryption scheme to yield very efficient public-key encryption. This is sometimes referred to as the KEM-DEM paradigm for PKE [17]. Examples include El Gamal encryption [31] and the Elliptic Curve Integrated Encryption Scheme (ECIES) standardized in ANSI X9.63 [15].

Alice

Bob

(ek,dk) ← Π.KeyGen(p)

ek,p −−−−−−−−→

(K,c ) ← Π.Encaps(p,ek) Π c ← Ξ.Encrypt(K,m) Ξ

c ,c ←−−−Π−−Ξ−−−

K(cid:48) ← Π.Decaps(p,dk,c )

Π

m ← Ξ.Decrypt(K(cid:48),c )

Ξ

Fig. 7. Sending a message using the KEM-DEM paradigm

Most applications of key establishment require at least one party (typically, a server) to authenticate their identity. One approach to achieving this is for the server to acquire a certificate of authenticity for their long-term, static KEM encapsulation key. This certificate can then be provided to a client as proof that the key is associated with the server’s identity. An example description of key establishment in this setting is given below and depicted in Fig. 8. The example uses a simplified key confirmation process (see Sec. 4.4).

Alice (server)

Bob (client)

Fig. 8. Unilateral authenticated key establishment using a KEM

This section describes an alternative approach to unilaterally authenticated key establishment using a KEM. Compared to the example in Sec. 5.2.2, Alice and Bob will now have the opposite roles in the protocol. Specifically, Bob is now the authenticated party (e.g., a web server), while Alice is the unauthenticated party (e.g., a browser client). Ephemeral KEM key-pair generation will now be performed by the client (i.e., Alice), and Alice will discard the KEM key pair once the connection is established. The server will not use a long-term, static KEM key pair but will need to establish his identity through other means. In this example, identity establishment will be done via a certificate that associates a particular digital signature verification key with Bob’s identity.

The protocol proceeds as follows (see Fig. 9.)

Alice (client)

Bob (server)

1.

static: (vkB,skB)

,Bob]

cert[vk B

(K(cid:48) ,K(cid:48)(cid:48)) ← KDF(K )

A

A A

Fig. 9. Using a KEM for key establishment with unilateral authentication

This section presents a static-ephemeral key-establishment scheme with unilateral authentication, as described in [32]. The scheme combines a shared secret key generated by a static KEM key pair with a shared secret key produced by a freshly generated, ephemeral KEM key pair. Just as in Example 5.2.2, one party possesses a static KEM key pair that is associated with a certificate.

KEMTLS is a protocol with similar elements to this example, though it includes additional features that are not presented here [33]. In particular, KEMTLS utilizes KEM-based authentication and also combines two shared secret keys: one generated by a static KEM key pair and one by an ephemeral KEM key pair.

Alice (client)

Bob (server)

1.

static: (ekB,dkB)

, p, Bob]

cert[ek B

B ob p, [e k−B, ]

ce rt ←− − − − − − − − −

, p, Bob] invalid, abort.

Fig. 10. Static-ephemeral unilateral authenticated key establishment using KEMs

This section presents a bilaterally authenticated key-establishment scheme using KEMs, as described in [32]. In this example, both Alice and Bob are authenticated using static KEM key pairs associated with certificates. The KEM shared secret keys produced using their static key pairs contribute to the final key and a shared secret key produced using a freshly generated ephemeral KEM key pair. This scheme achieves weak forward secrecy [32, 34].

As with other examples, Alice and Bob will need to negotiate which KEM Π and parameter set p they will use for the ephemeral key pair prior to protocol execution. As in Example 5.2.3, H denotes a KDF. Note that in [32] H is chosen to be a cryptographic hash function. There is no key-confirmation step included in this example, but one could be added.

Alice (client)

Bob (server)

Fig. 11. Authenticated key establishment using KEMs

References

[1] Barker EB, Chen L, Roginsky A, Vassilev A, Davis R (2018) Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography (Depart-ment of Commerce, Washington, D.C.), NIST Special Publication (SP) NIST SP 800-56Ar3. https://doi.org/10.6028/NIST.SP.800-56Ar3

[2] Barker EB, Chen L, Roginsky A, Vassilev A, Davis R, Simon S (2019) Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography (Depart-ment of Commerce, Washington, D.C.), NIST Special Publication (SP) NIST SP 800-56Br2. https://doi.org/10.6028/NIST.SP.800-56Br2

[3] National Institute of Standards and Technology (2024) Module-Lattice-Based Key-Encapsulation Mechanism Standard (Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publications (FIPS) NIST FIPS 203. https://doi.org/10.6028/NIST.FIPS.203

[4] Moody D, Perlner R, Regenscheid A, Robinson A, Cooper D (2024) Transition to Post-Quantum Cryptography Standards (Department of Commerce, Washington, D.C.), NIST Internal Report (IR) NIST IR 8547ipd. https://doi.org/10.6028/NIST.IR.8547.ipd

[5] National Institute of Standards and Technology (2019) Security Requirements for Cryptographic Modules (Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publications (FIPS) NIST FIPS 140-3,. https://doi.org/10.6028/NIST.FIPS.140-3

[6] Barker EB, Kelsey J (2015) Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Department of Commerce, Washington, D.C.), NIST Special Publication (SP) NIST SP 800-90Ar1. https://doi.org/10.6028/NIST.SP.800-90Ar1

[7] Sönmez Turan M, Barker E, Kelsey J, McKay K, Baish M, Boyle M (2018) Recommendation for the Entropy Sources Used for Random Bit Generation (Department of Commerce, Washington, D.C.), NIST Special Publication (SP) NIST SP 800-90B. https://doi.org/10.6028/NIST.SP.800-90B

[8] Barker EB, Kelsey JM, McKay KA, Roginsky AL, Sönmez Turan M (2025) Recommendation for Random Bit Generator (RBG) Constructions (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-90C. https://doi.org/10.6028/NIST.SP.800-90C

[9] Dworkin M (2007) Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-38D. https://doi.org/10.6028/NIST.SP.800-38D

[10] Barker E, Branstad D, Smid M (2015) A Profile for U.S. Federal Cryptographic Key Man-agement Systems (CKMS) (National Institute of Standards and Technology, Gaithers-burg, MD), NIST Special Publication (SP) NIST SP 800-152. https://doi.org/10.6028/NIST.SP.800-152

[11] Shoup V (2001) A Proposal for an ISO Standard for Public Key Encryption, Cryptology ePrint Archive, Paper 2001/112. Available at https://eprint.iacr.org/2001/112.

[12] Cramer R, Shoup V (2003) Design and analysis of practical public-key encryption schemes secure against adaptive chosen ciphertext attack. SIAM Journal on Computing 33(1):167–226. https://doi.org/10.1137/S0097539702403773

[13] Herranz J, Hofheinz D, Kiltz E (2006) Some (in)sufficient conditions for secure hybrid encryption, Cryptology ePrint Archive, Paper 2006/265. Available at https://eprint.iacr.org/2006/265.

[14] Brainard J, Kaliski B, Turner S, Randall J (2010) Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS), RFC 5990. https://doi.org/10.17487/RFC5990.

[15] American National Standards Institute (2011) ANSI X9.63-2011, (R2017) - Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography (Accredited Standards Committee X9, Annapolis, MD). Available at https://webstore.ansi.org/standards/ascx9/ansix9442007r2017.

[16] American National Standards Institute (2007) ANSI X9.44-2007 (R2017), Public Key Cryptography for the Financial Services Industry: Key Establishment Using Integer Factorization Cryptography (Accredited Standards Committee X9, Annapolis, MD). Available at https://webstore.ansi.org/standards/ascx9/ansix9442007r2017.

[17] Katz J, Lindell Y (2020) Introduction to Modern Cryptography (Chapman & Hall/CRC, Boca Raton, FL), 3rd Ed.

[18] Barker EB, Roginsky A, Davis R (2020) Recommendation for Cryptographic Key Generation (Department of Commerce, Washington, D.C.), NIST Special Publication (SP) NIST SP 800-133r2. https://doi.org/10.6028/NIST.SP.800-133r2

[19] Barker E (2020) Recommendation for Key Management: Part 1 – General (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-57pt1r5. https://doi.org/10.6028/NIST.SP.800-57pt1r5

[20] Chen L (2022) Recommendation for Key Derivation Using Pseudorandom Functions (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-108r1-upd1, Includes updates as of February 2, 2024. https://doi.org/10.6028/NIST.SP.800-108r1-upd1

[21] Barker EB, Chen L, Davis R (2020) Recommendation for Key-Derivation Methods in Key-Establishment Schemes (Department of Commerce, Washington, D.C.), NIST Special Publication (SP) NIST SP 800-56Cr2. https://doi.org/10.6028/NIST.SP.800-56Cr2

[22] Brockhaus H, von Oheimb D, Ounsworth M, Gray J (2025) Internet X.509 Public Key Infrastructure – Certificate Management Protocol (CMP), RFC 9810. https://doi.org/10.17487/RFC9810.

[23] Driscoll F, Parsons M, Hale B (2024) Terminology for Post-Quantum Traditional Hybrid Schemes (Internet Engineering Task Force), Internet-Draft draft-ietf-pquip-pqt-hybrid-terminology-05. Work in Progress. Available at https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/05/.

[24] Barbosa M, Connolly D, Duarte JD, Kaiser A, Schwabe P, Varner K, Westerbaan B (2024) X-Wing. IACR Communications in Cryptology 1(1). https://doi.org/10.62056/a3qj89n4e

[25] Giacon F, Heuer F, Poettering B (2018) KEM combiners. Public-Key Cryptography – PKC 2018, eds Abdalla M, Dahab R (Springer International Publishing, Cham), pp 190–218.

[26] Avanzi R, Bos J, Ducas L, Kiltz E, Lepoint T, Lyubashekvsky V, Schanck JM, Schwabe P, Seiler G, Stehlé D (2021) CRYSTALS-Kyber Algorithm Specifications and Supporting Documentation (version 3.02). Available at https://pq-crystals.org/kyber/data/kyber-specification-round3-20210804.pdf.

[27] Avanzi R, Bos J, Ducas L, Kiltz E, Lepoint T, Lyubashevsky V, Schanck JM, Schwabe P, Seiler G, Stehlé D (2020) CRYSTALS-Kyber Algorithm Specifications and Supporting Documentation, Third-round submission to the NIST’s post-quantum cryptography standardization process. Available at https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization/round-3-submissions.

[28] Almeida JB, Olmos SA, Barbosa M, Barthe G, Dupressoir F, Grégoire B, Laporte V, Léchenet JC, Low C, Oliveira T, Pacheco H, Quaresma M, Schwabe P, Strub PY (2024) Formally verifying Kyber Episode V: Machine-checked IND-CCA security and correctness of ML-KEM in EasyCrypt, Cryptology ePrint Archive, Paper 2024/843. Available at https://eprint.iacr.org/2024/843.

[29] Regev O (2005) On Lattices, Learning with Errors, Random Linear Codes, and Cryptography. Proceedings of the Thirty-Seventh Annual ACM Symposium on Theory of Computing STOC ’05 (Association for Computing Machinery, New York, NY, USA), pp 84–93. https://doi.org/10.1145/1060590.1060603.

[30] Langlois A, Stehlé D (2015) Worst-case to average-case reductions for module lattices. Designs, Codes and Cryptography 75(3):565–599. https://doi.org/10.1007/s10623-09938-4.

[31] ElGamal T (1985) A public key cryptosystem and a signature scheme based on discrete logarithms. IEEE transactions on information theory 31(4):469–472. https://doi.org/10.1109/TIT.1985.1057074

[32] Bos J, Ducas L, Kiltz E, Lepoint T, Lyubashevsky V, Schanck JM, Schwabe P, Seiler G, Stehle D (2018) CRYSTALS - Kyber: A CCA-Secure Module-Lattice-Based KEM. 2018 IEEE European Symposium on Security and Privacy (EuroSP), pp 353–367. https://doi.org/10.1109/EuroSP.2018.00032

[33] Schwabe P, Stebila D, Wiggers T (2020) Post-quantum TLS without handshake signatures. Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, pp 1461–1480. https://doi.org/10.1145/3372297.3423350

[34] Canetti R, Krawczyk H (2001) Analysis of key-exchange protocols and their use for building secure channels. Advances in Cryptology — EUROCRYPT 2001 (Springer, Berlin, Heidelberg), pp 453–474. https://doi.org/10.1007/3-540-44987-6_28

[35] Sönmez Turan M, Brandão LTAN (2024) Keyed-Hash Message Authentication Code (HMAC): Specification of HMAC and Recommendations for Message Authentication (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-224 ipd. https://doi.org/10.6028/NIST.SP.800-224.ipd

[36] Dworkin M (2010) Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-38B. https://doi.org/10.6028/NIST.SP.800-38B

[37] Kelsey J, Chang SJ, Perlner R (2016) SHA-3 Derived Functions: cSHAKE, KMAC, Tuple-Hash and ParallelHash (Department of Commerce, Washington, D.C.), NIST Special Publication (SP) NIST SP 800-185. https://doi.org/10.6028/NIST.SP.800-185

CAVP Cryptographic Algorithm Verification Program

CMVP Cryptographic Module Verification Program

DRBG Deterministic Random Bit Generator

FIPS Federal Information Processing Standards

IND-CCA Indistinguishability under Chosen Ciphertext Attack

IND-CPA Indistinguishability under Chosen Plaintext Attack

ITL Information Technology Laboratory

KC Key Confirmation

KDF Key-Derivation Function

KDM Key-Derivation Method

KEM Key-Encapsulation Mechanism

MAC Message Authentication Code

ML-KEM Module-Lattice-Based Key-Encapsulation Mechanism

NIST National Institute of Standards and Technology

PKE Public-Key Encryption

PoP Proof of Possession

RBG Random Bit Generator

SP Special Publication

TLS Transport Layer Security

TTP — Trusted Third Party

This section is informative.

approved — FIPS-approved and/or NIST-recommended. An algorithm or technique that is either 1) specified in a FIPS or NIST recommendation, 2) adopted in a FIPS or NIST recommendation, or 3) specified in a list of NIST-approved security functions.

ciphertext With regard to KEMs, a bit string that is produced by the encapsulation algorithm and used as an input to the decapsulation algorithm.

computationally bounded adversary An adversarial algorithm that is constrained in running time and memory, and is thus unlikely to break a cryptosystem under consideration. The nature of the constraints depends on the context, including the desired security strength of the cryptosystem.

cryptanalytically relevant quantum computer — A device capable of using quantum algorithms to break a cryptosystem that is secure against classical (i.e., non-quantum) computers.

decapsulation key A cryptographic key produced by a KEM during key generation and used during decapsulation.

destroy — An action applied to a key or other piece of secret data. After a key or piece of secret data is destroyed, no information about its value can be recovered.

efficient (cryptographic) algorithm An algorithm whose running time is practical for the relevant security strength.

encapsulation key A cryptographic key produced by a KEM during key generation and used by the encapsulation algorithm.

ephemeral key A cryptographic key that is generated for each execution of a cryptographic process (e.g., key establishment) and meets other requirements of the key type (e.g., unique to each message or session).

hash function A function on arbitrarily long bit strings in which the length of the output is fixed. At a minimum, the hash function must be one-way and collision-resistant.

identifier A bit string that is associated with a person, device, or organization. It may be an identifying name or something more abstract (e.g., a string consisting of an IP address).

key agreement A (pair-wise) key-establishment procedure in which the resultant secret keying material is a function of information contributed by both participants so that neither party can predetermine the value of the secret keying material independent of the contributions of the other party. Contrast with key transport.

key combiner A function that takes multiple keys or shared secret values as input (possibly along with other information) and produces a single combined key.

key confirmation A procedure that provides assurance to one party (i.e., key-confirmation recipient) that another party (i.e., key-confirmation provider) possesses the correct secret keying material and/or shared secret from which that secret keying material is derived.

key-confirmation provider The party that provides assurance to the other party (i.e., the recipient) that the two parties have indeed established a shared secret key or other keying material.

key-confirmation recipient The party that receives assurance from the other party (i.e., the provider) that the two parties have indeed established a shared secret key or other keying material.

key-derivation method A method used to derive keying material from initial shared secrets and possibly other information.

key-derivation key A key used as an input to a key-derivation method to derive additional keying material.

key establishment A procedure that results in secret keying material that is shared among different parties. Key agreement, using a KEM, and key transport are all types of key establishment.

keying material A bit string such that any non-overlapping, contiguous segments of the string with required lengths can be used as secret keys, secret initialization vectors, and other secret parameters.

key pair A set of two keys with the property that one key can be made public, while the other key must be kept private. In this publication, this could refer to either the (encapsulation key, decapsulation key) key pair of a KEM or the (encryption key, decryption key) key pair of a public-key encryption (PKE) scheme.

key transport A (pair-wise) key-establishment procedure whereby one party (i.e., the sender) selects a value for the secret keying material and then securely distributes the value to another party (i.e., the receiver). Contrast with key agreement.

message authentication code (MAC) A family of symmetric-key cryptographic algorithms that act on input data of arbitrary length to produce an output value of a specified length (i.e., the MAC of the input data). The MAC can be employed to authenticate the origin of the input data and/or provide data integrity protection.

message authentication code (MAC) tag Data obtained from the output of a MAC algorithm (possibly by truncation) that can be used by an entity to securely verify the integrity and origin of the information used as input to the MAC algorithm.

must Indicates a requirement of this recommendation that might not be testable by a CMVP testing lab.

negligible Extremely small. Typically quantifies the probability of an undesirable event that might occur during the lifetime of a cryptosystem (including during attacks by computationally bounded adversaries).

party An individual (person), organization, device, or process. In this recommendation, there are typically two parties (e.g., Party A and Party B, Alice and Bob) that jointly perform the key-establishment process using a KEM.

post-quantum algorithm A cryptographic algorithm that is believed to be secure, even against adversaries who possess a cryptanalytically relevant quantum computer.

pseudorandom A process (or data produced by a process) whose outcome is deterministic yet also appears effectively random if the internal action of the process is hidden from observation. For cryptographic purposes, “effectively random” means “computationally indistinguishable from random within the limits of the intended security strength.”

public channel A communication channel between two honest parties that can be observed and compromised by third parties.

quantum-vulnerable algorithm A cryptographic algorithm that is believed to be secure against adversaries who possess only a classical computer but is known to be insecure against adversaries who possess a cryptanalytically relevant quantum computer.

security strength A number associated with the amount of work that is required to break a cryptographic algorithm or system.

seed A bit string used as input to a pseudorandom process.

shall Used to indicate a requirement of this document that will be tested by a CMVP testing lab.

shared secret A secret value that has been computed during a key-establishment scheme, is known by all participating parties, and is used as input to a key-derivation method to produce keying material.

shared secret key A shared secret that can be used directly as keying material or as a symmetric key.

should Used to indicate a strong recommendation but not a requirement of this document. Ignoring the recommendation could lead to undesirable results.

side-channel attack An attack enabled by the leakage of information from a deployed cryptosystem. Characteristics that could be exploited in a side-channel attack include timing, power consumption, and electromagnetic and acoustic emissions.

static key A key that is intended for use for a relatively long period of time and is typically intended for use in many instances of a cryptographic key-establishment scheme. Contrast with ephemeral key.

symmetric-key algorithm A cryptographic algorithm that uses the same secret key for an operation and its complement (e.g., encryption and decryption). Also called a secret-key algorithm.

trusted third party An entity other than the owner and verifier that is trusted by the owner, the verifier, or both to provide certain services.

Appendix C. Cryptographic Components

When key confirmation requires the use of a MAC algorithm, it shall be an approved MAC algorithm (i.e., HMAC, AES-CMAC, or KMAC). HMAC is specified in SP 800-224 [35] and requires the use of an approved hash function. AES-CMAC is specified in SP 800-38B [36] for the AES block cipher algorithm specified in FIPS 197. KMAC is specified in SP 800-185 [37]. In addition, AES-GMAC (specified in [9]) is an approved MAC algorithm and may be used.

MAC Tag Computation for Key Confirmation. Key confirmation can be performed as one or more additional steps in a KEM scheme. The computation of a MAC tag is represented as follows:

To compute a MacTag:

Table 1. Approved MAC algorithms for key confirmation

Appendix C.2. Nonces

A nonce is a time-varying value with a negligible chance of repeating. A decapsulator may be required to provide a public nonce that is used for key-confirmation purposes. This circumstance arises when the decapsulator’s public key is static.

A nonce may be composed of one or more of the following components, though other components may also be appropriate:

When a nonce is required for key-confirmation purposes as specified in this recommen-dation, it should be a random nonce that contains a random bit string output from an approved random bit generator, where both the security strength supported by the in-stantiation of the random bit generator and the bit length of the random bit string are greater than or equal to the targeted security strength of the key-establishment scheme in which the nonce is used during key confirmation. When feasible, the bit length of the random bit string should be at least twice the targeted security strength. For details con-cerning the security strength supported by an instantiation of a random bit generator, see the SP 800-90 series of publications [6–8].

As part of the proper implementation of this recommendation, system users and/or agents trusted to act on their behalf should determine whether the components selected for in-clusion in any required nonces meet their security requirements.

Appendix D. Changes From Draft SP 800-227