NIST SP 800-133 Rev. 2 日本語訳

NIST Special Publication 800-133

Revision 2

Elaine Barker Allen Roginsky Richard Davis

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

NIST Special Publication 800-133

Revision 2

Elaine Barker Allen Roginsky

Computer Security Division Information Technology Laboratory

Richard Davis

National Security Agency

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

June 2020

U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary

National Institute of Standards and Technology

Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology

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.

National Institute of Standards and Technology Special Publication 800-133 Revision 2 Natl. Inst. Stand. Technol. Spec. Publ. 800-133 Rev 2, 36 pages (June 2020) CODEN: NSPUE2

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

Comments on this publication may be submitted to:

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: SP-800-133_Comments@nist.gov

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

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.

Cryptography is often used in an information technology security environment to protect data that is sensitive, has a high value, or is vulnerable to unauthorized disclosure or undetected modification during transmission or while in storage. Cryptography relies upon two basic components: an algorithm (or cryptographic methodology) and a cryptographic key. This Recommendation discusses the generation of the keys to be managed and used by the approved cryptographic algorithms.

asymmetric key; key agreement; key derivation; key generation; key wrapping; key replacement; key transport; private key; public key; symmetric key.

The National Institute of Standards and Technology (NIST) gratefully acknowledges and appreciates contributions by the public and private sectors whose thoughtful and constructive comments improved the quality and usefulness of this publication.

NOTICE: The Information Technology Laboratory (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 infringement in the use of this publication.

Cryptography is often used in an information technology security environment to protect data that is sensitive, has a high value, or is vulnerable to unauthorized disclosure or undetected modification during transmission, storage, or use. Cryptography relies upon two basic components: an algorithm (or cryptographic methodology) and, often, a cryptographic key. The algorithm is a mathematical process, and the key is a parameter used by that process. The National Institute of Standards and Technology (NIST) has developed a wide variety of Federal Information Processing Standards (FIPS) and NIST Special Publications (SPs) to specify and approve cryptographic algorithms for use by the Federal Government. In addition, guidance has been provided on the management of the cryptographic keys to be used with these approved cryptographic algorithms. This Recommendation (i.e., SP 800-133) discusses the generation of the keys to be used with the approved cryptographic algorithms. The keys are either 1) generated using mathematical processing on the output of approved Random Bit Generators (RBGs) and possibly other parameters or 2) generated based on keys that are generated in this fashion.

This Recommendation addresses the generation of the cryptographic keys used in cryptography. Key generation includes the generation of a key using the output of a random bit generator (RBG), the derivation of a key from another key, the derivation of a key from a password, and key agreement performed by two entities using an approved key-agreement scheme. All keys shall be based directly or indirectly on the output of an approved RBG. For the purposes of this Recommendation, keys that are derived during a key-agreement transaction (see SP 800-56A and SP 800-56B), derived from another key using a key derivation function (see SP 800-108), or derived from a password for storage applications (see SP 800-13213 and Section 6.5) are considered to be indirectly generated from an RBG since an ancestor key¹⁴ or random value (e.g., the random value used to generate a key-agreement key pair) was obtained directly from the output of an approved RBG. Two classes of cryptographic algorithms that require cryptographic keys have been approved for use by the Federal Government: asymmetric-key algorithms and symmetric-key algorithms. The generation of keys for these algorithm classes is discussed in Sections 5 and 6, respectively.

Cryptographic keys shall be generated within FIPS 140-validated cryptographic modules. For explanatory purposes, consider the cryptographic module in which a key is generated to be the key-generating module. Any random value required by the key-generating module shall be generated within that module; that is, the RBG (or portion of the RBG¹⁵) that generates the random value shall be implemented within the FIPS 140 cryptographic module that generates the key. The generated keys shall be transported (when transportation is necessary) using secure channels and shall be used by their associated cryptographic algorithm within FIPS 140-validated cryptographic modules.

A method (e.g., an RBG or a key and its associated cryptographic algorithm) supports a given security strength if the security strength provided by that method is equal to or greater than the security strength required for protecting the target data; the actual security strength provided can be higher than required. Security strength supported by an RBG: A well-designed RBG supports a given security strength only if the amount of entropy (i.e., the randomness) available in the RBG is equal to or greater than that security strength. The support of a given security strength also requires a commensurate security strength for the confidentiality protection afforded to the entropy bits entered into the RBG (and other parameters determining the RBG’s state); when used for the generation of keys and other secret values, a commensurate security strength is also required for the confidentiality and integrity protection that will be provided to the RBG output. For information regarding the security strength that can be supported by approved RBGs, see SP 800-90A.16 Security strength supported by an algorithm: Discussions of cryptographic algorithms and the security strengths they can support given certain choices of parameters and/or key lengths are provided in SP 800-57, Part 1.17 The security strength of a cryptographic algorithm that uses keys of a certain size (i.e., the key’s length) is assessed under the assumption that those keys are generated using an approved process that outputs keys of the requisite size and type while providing an appropriate amount of min-entropy. It is assumed that this key-generation process is capable of supporting security strengths that are equal to or greater than the security strength assessed for the cryptographic algorithm. (Both the min-entropy and the security strength are measured in bits.) Security strength supported by a key: The security strength that can be supported by a key depends on: 1) the algorithm with which it is used, 2) the size of the key (see SP 800-57, Part 1), 3) the process that generated the key (e.g., the security strength supported by the RBG that was used to generate the key), and 4) how the key was handled (e.g., the security strength available in the method used to transport the key). The use of such terms as “security strength supported by a key” or “key supports a security strength” assumes that these factors have been taken into consideration. For example, if an approved RBG that supports a security strength of 128 bits has been used to generate a 128-bit key, and if (immediately after generation) the key is used with AES-128 to encrypt target data, then the key may be said to support a security strength of 128 bits in that encryption operation (for as long as the key is kept secret). However, if the 128-bit AES key is generated using an RBG that supports a security strength of only 112 bits, then the key can only support a security strength of 112 bits even though its length is still 128 bits (i.e., the security strength of the key has been determined by the process used for its generation).

where

The algorithm and/or application with which B will be used and the security strength that B is intended to support will determine the required bit length of B: bLen shall meet the relying application's or algorithm’s length requirement for a value of the bit string B to be used as intended in support of the targeted security strength. For example, if B is to be used as an AES key, then bLen shall be an approved AES key length that supports the required security strength for protecting the target data. As another example, according to FIPS 186, if B is to be used as a seed in the specified process of generating provably prime factors of an RSA modulus n, then bLen shall be twice the security strength associated with (the bit length of) n.

Since there are no restrictions on the selection of V (other than its length and independence from U), a conservative approach necessitates an assumption that the process used to select U provides most (if not all) of the required entropy, which − when measured in bits − cannot exceed the length of U (i.e., bLen). Therefore, the approved RBG from which U is obtained shall be capable of providing the requisite entropy for B during the generation of U (i.e., at least bLen bits of entropy are provided during the seeding of the RBG). The independence requirement on U and V is interpreted in a computational and statistical sense: the computation of U does not depend on V, and the computation of V does not depend on U. Knowledge of the value of V (but not B) must provide no advantage to a party intent on gaining insight into an (as-yet-unknown) value of U. The value of V may be selected using a process that provides little entropy (e.g., V may be assigned a fixed, public value). Nevertheless, in cases where the value of V is intended to be kept secret, knowledge of the value of U (but not B) must yield no additional information concerning the value selected for V. Given that U is the output of an approved RBG, the following are examples of independently selected V values:

Asymmetric-key algorithms (also known as public-key algorithms) require the use of asymmetric key pairs consisting of a private key and a corresponding public key. A key pair can be used for the generation and verification of digital signatures (see Section 5.1) or for key establishment (see Section 5.2). Each public/private key pair is associated with only one entity; this entity is known as the key-pair owner. Key pairs shall be generated by:

After key-pair generation, the key pair is retained and used by its owner. If the key pair was generated by a Trusted Party, both the owner and any relying party must trust that party not to use the private key of the key pair. The public key may be known by or provided to whomever needs to use it when interacting with the owner (see Section 5.3).

Key establishment includes both key agreement and key transport. Key agreement is a method of key establishment in which the resultant secret keying material is a function of information contributed by all participants in the key-establishment process (usually only two participants) so that no party can predetermine the value of the keying material independent of any other party’s contribution. For key-transport, one party (the sender) selects a value for the secret keying material and then securely distributes that value to one or more other parties (the receiver(s)). Approved methods for generating the asymmetric key pairs used by approved key-establishment schemes between two parties are specified in SP 800-56A (for schemes that use finite-field or elliptic-curve cryptography) and SP 800-56B (for schemes that use integer-factorization cryptography, such as RSA). Values of B, computed as shown in Section 4, shall be used to provide the random values¹⁹ needed to generate key pairs for the finite field or elliptic curve schemes in SP 800-56A or to generate key pairs for the integer-factorization schemes specified in SP 800-56B. The maximum security strength that can be supported by the approved key-establishment schemes and the key sizes used by these schemes is provided in SP 800-57, Part 1.

A general discussion of the distribution of asymmetric key pairs is provided in SP 800-57, Part 1. Key pairs may either be static or ephemeral. Static key pairs are intended to be used multiple times; ephemeral keys are usually used only once. The private key of a key pair shall be kept secret. It shall either be generated 1) within the key-pair owner’s cryptographic module (i.e., the key-pair owner’s key-generating module) or 2) within the cryptographic module of an entity trusted by the key-pair owner and any relying party not to misuse the private key or reveal it to other entities (i.e., the key pair is generated within the key-generating module of a Trusted Party and securely transferred to the key-pair owner’s cryptographic module). If a private key is ever output from a cryptographic module, the key shall be output and transferred in a form and manner that provides appropriate assurance²⁰ of its confidentiality and integrity (e.g., using manual methods and multi-party control procedures or automated key-transport methods). The protection shall provide appropriate assurance that only the key-pair owner and/or the party that generated the key pair will be able to determine the value of the plaintext private key (e.g., the confidentiality and integrity protection for the private key uses a cryptographic mechanism that is at least as strong as the (maximum) security strength that must be supported by the asymmetric-key algorithm that will use the private key). The public key of a key pair may be made public. However, it shall be distributed and verified in a manner that assures its integrity and association with the key-pair owner (e.g., in the case of a static public key, this may be accomplished using an X.509 certificate that provides a level of cryptographic protection that is at least as strong as the security strength associated with the key pair).

Key pairs need to be replaced if the private key is compromised. Key pairs also need to be replaced occasionally to limit the amount of information that is protected by the key pair in case of a compromise of the private key (see Section 5.3 of SP 800-57, Part 1). Section 5.3.4 of SP 800-57, Part 1 discusses the usage period for each key of the key pair for both digital signature and key-establishment key pairs. When asymmetric key pairs need to be replaced, they shall be generated and distributed as specified in Sections 5.1, 5.2, or 5.3, as appropriate.

Symmetric-key algorithms use the same (secret) key to both apply cryptographic protection to information²¹ and to remove or verify the protection.²² Keys used with symmetric-key algorithms must be known by only the entities authorized to apply, remove, or verify the protection and are commonly known as secret keys. A secret key is often known by multiple entities that are said to share or own the secret key, although it is not uncommon for a key to be generated, owned, and used by a single entity (e.g., for secure storage). A secret key shall be generated by:

Section 6.1 discusses the generation of symmetric keys that are obtained from the output of an RBG. Section 6.2 discusses the derivation of symmetric keys. Section 6.3 specifies approved techniques for combining a symmetric key with other symmetric keys and/or additional data. At some point, a symmetric key needs to be replaced for a number of possible reasons (e.g., its cryptoperiod has been exceeded, or it has been compromised; see SP 800-57 Part 1). Section 6.4 discusses key replacement.

Symmetric keys are often obtained from the output of an approved key-derivation method (KDM), which is a cryptographic process specifically designed to transform secret input values into bit strings that can be parsed into cryptographic keys and/or other secret keying material.

Approved KDMs have been constructed from more basic cryptographic components, such as an approved hash function, as specified in FIPS 180 or FIPS 202; HMAC (using an approved hash function), as specified in FIPS 198; AES-CMAC, as specified in FIPS 197 and SP 800-38B; or a KMAC variant, as specified in SP 800-185.

Depending on the application and the KDM, the input to a KDM may include, for example, one or more of the following:

Approved key-derivation methods can be divided into two categories:

When an approved key-agreement scheme is available within an entity’s key-generating module, a symmetric key may be established with another entity that has the same capability. This process results in a symmetric key that is shared between the two entities participating in the key-agreement transaction. SP 800-56A and SP 800-56B provide several methods for pairwise key agreement. Asymmetric key-agreement keys are used with a key-agreement primitive algorithm to generate a shared secret. The shared secret is provided to a key-derivation method to derive keying material. SP 800-56C specifies approved key-derivation methods for the key-agreement schemes in SP 800-56A and SP 800-56B.

The maximum security strength that can be supported by a key derived in this manner is dependent on: 1) the security strength supported by the asymmetric key pairs (as used during key establishment), 2) the key-derivation method used, 3) the length of the derived key, and 4) the algorithm with which the derived key will be used. See SP 800-57, Part 1.

Symmetric keys are often derived using a key-derivation function (KDF) and a preexisting key known as a key-derivation key. For example, the preexisting key may have been:

Approved methods for key derivation are provided in SP 800-108, which specifies approved KDFs for deriving keys from a pre-shared (i.e., preexisting) key-derivation key. The KDFs are based on HMAC (as specified in FIPS 198) and CMAC (as specified in SP 800-38B). If the derived keys need to be distributed to other entities, this may be accomplished as discussed in Section 6.4. In addition to the symmetric-key algorithm with which a derived key will be used, the security strength that can be supported by the derived key depends on the security strength supported by the key-derivation key and the KDF used (see SP 800-57, Part 1 for the maximum security strength that can be supported by HMAC and CMAC, and see SP 800-10725 for further discussions about the security strength of HMAC).

When symmetric keys K₁, …, Kₙ are generated and/or established independently, they may be combined within a key-generating module to form a key K. Other items of data (D₁, …, Dₘ) can also be combined with the Kᵢ to form K under the conditions specified below. Note that while the Kᵢ values are required to be secret, the Dⱼ values need not be kept secret.

The independent generation/establishment of the component keys K₁, …, Kₙ is interpreted in a computational and a statistical sense; that is, the computation of any particular Kᵢ value does not depend on any one or more of the other Kᵢ values, and it is not feasible to use knowledge of any proper subset of the Kᵢ values to obtain any information about the remaining Kᵢ values.

When their use is permitted, D₁, …, Dₘ shall be generated or obtained using methods that ensure their independence from the values of the component keys K₁, …, Kₙ.

The required independence of the component keys from these other items of data is also interpreted in a computational and a statistical sense. This means that the computation of the Kᵢ values does not depend on any of the Dⱼ values, the computation of the Dⱼ values does not depend on any of the Kᵢ values, and knowledge of the Dⱼ values yields no information that can feasibly be used to gain insight into the Kᵢ values. In cases where some (or all) of the Dⱼ values are secret and the rest of the Dⱼ values (if any) are public, “independence” also means that knowledge of the Kᵢ values and public Dⱼ values yields no information that can feasibly be used to gain insight into the secret Dⱼ values.

The approved methods for combining the component keys and other data are:

b. The methods used to generate or establish the component keys shall be such that at least one of those methods provides min-entropy equal to or greater than the min-entropy required for the resulting key K.

Notes: a. HMAC-hash shall be an implementation of HMAC (as specified in FIPS 198, using an approved hash function hash) with a security strength that meets or exceeds the targeted security strength of the algorithm or application that will rely on the resulting key K (see SP 800-57, Part 1).

The symmetric key generated within a key-generating module often needs to be shared with one or more other entities that have their own cryptographic modules. The key may be distributed manually or using an approved key-transport or symmetric key-wrapping method (see SP 800-56B, SP 800-38F, and SP 800-71). See SP 800-57, Part 1 for further discussion. The method used for key transport or key wrapping shall support the desired security strength needed to protect the target data (i.e., the data to be protected by the application or algorithm relying on the symmetric key). The requirements for the output of a key from a cryptographic module are discussed in FIPS 140.

Sometimes, a symmetric key may need to be replaced. This may be due to a compromise of the key or the end of the key’s cryptoperiod (see SP 800-57, Part 1). Replacement shall be accomplished through a rekeying process. Rekeying is the replacement of a key with a new key that is generated independent of the value of the old key (i.e., knowledge of the old key provides no knowledge of the value of the replaced key and vice versa).

When a compromised key is replaced, the new key shall be generated in a manner that provides assurance of its independence from the compromised key. The new key may be generated using any appropriate method in Section 6 with the following restrictions:

If an uncompromised symmetric key is to be replaced, it shall be replaced using any method in Section 6 that supports the required amount of security strength. However, if the key to be replaced was generated in a manner that depended (in whole or in part) on a password (see Sections 6.2.3), that password shall be changed prior to the generation of the new key.

FIPS 140

National Institute of Standards and Technology (2019) Security Requirements for Cryptographic Modules. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 140-3. https://doi.org/10.6028/NIST.FIPS.140-3 National Institute of Standards and Technology (2001) Security Requirements for Cryptographic Modules. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 140-2, Change Notice 2 December 03, 2002. https://doi.org/10.6028/NIST.FIPS.140-2

FIPS 140 IG National Institute of Standards and Technology, Canadian Centre for Cyber

FIPS 180

National Institute of Standards and Technology (2015) Secure Hash Standard (SHS). (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 180-4. https://doi.org/10.6028/NIST.FIPS.180-4

FIPS 186

National Institute of Standards and Technology (2019) Digital Signature Standard (DSS). (U.S. Department of Commerce, Washington, DC), Draft Federal Information Processing Standards Publication (FIPS) 186-5. https://doi.org/10.6028/NIST.FIPS.186-5-draft

FIPS 197

National Institute of Standards and Technology (2001) Advanced Encryption Standard (AES). (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 197. https://doi.org/10.6028/NIST.FIPS.197

FIPS 198

National Institute of Standards and Technology (2008) The Keyed-Hash Message Authentication Code (HMAC). (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 198-1. https://doi.org/10.6028/NIST.FIPS.198-1

FIPS 202

National Institute of Standards and Technology (2015) SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 202. https://doi.org/10.6028/NIST.FIPS.202

SP 800-38A Dworkin MJ (2001) Recommendation for Block Cipher Modes of Operation: Methods and Techniques. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-38A. https://doi.org/10.6028/NIST.SP.800-38A

SP 800-38B Dworkin MJ (2016) Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-38B, Includes updates as of October 06, 2016. https://doi.org/10.6028/NIST.SP.800-38B

SP 800-38F Dworkin MJ (2012) Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-38F. https://doi.org/10.6028/NIST.SP.800-38F

SP 800-56A Barker EB, Chen L, Roginsky A, Vassilev A, Davis R (2018) Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56A, Rev. 3. https://doi.org/10.6028/NIST.SP.800-56Ar3

SP 800-56B Barker EB, Chen L, Roginsky A, Vassilev A, Davis R, Simon S (2019) Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56B, Rev. 2. https://doi.org/10.6028/NIST.SP.800-56Br2.

SP 800-56C Barker EB, Chen L, Davis R (2018) Recommendation for Key-Derivation Methods in Key-Establishment Schemes. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56C, Rev. 1. https://doi.org/10.6028/NIST.SP.800-56Cr1

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

SP 800-67 Barker EB, Mouha N (2017) Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-67, Rev. 2. https://doi.org/10.6028/NIST.SP.800-67r2

SP 800-71 Barker EB, Barker WC (2018) Recommendation for Key Establishment Using Symmetric Block Ciphers. (National Institute of Standards and Technology, Gaithersburg, MD), Draft NIST Special Publication (SP) 800-71. https://csrc.nist.gov/publications/detail/sp/800-71/draft

SP 800-90A Barker EB, Kelsey JM (2015) Recommendation for Random Number Generation Using Deterministic Random Bit Generators. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-90A, Rev. 1 https://doi.org/10.6028/NIST.SP.800-90Ar1

SP 800-90B Sönmez Turan M, Barker EB, Kelsey JM, McKay KA, Baish ML, Boyle M (2018) Recommendation for the Entropy Sources Used for Random Bit Generation. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-90B. https://doi.org/10.6028/NIST.SP.800-90B

SP 800-90C Barker EB, Kelsey JM (2016) Recommendation for Random Bit Generator (RBG) Constructions. (National Institute of Standards and Technology, Gaithersburg, MD), Draft NIST Special Publication (SP) 800-90C. https://csrc.nist.gov/publications/detail/sp/800-90c/draft

SP 800-107 Dang QH (2012) Recommendation for Applications Using Approved Hash Algorithms. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-107, Rev. 1. https://doi.org/10.6028/NIST.SP.800-107r1

SP 800-108 Chen L (2009) Recommendation for Key Derivation Using Pseudorandom Functions (Revised). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-108. https://doi.org/10.6028/NIST.SP.800-108

SP 800-131A Barker EB, Roginsky A (2019) Transitioning the Use of Cryptographic Algorithms and Key Lengths. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-131A, Rev. 2. https://doi.org/10.6028/NIST.SP.800-131Ar2.

SP 800-132 Sönmez Turan M, Barker EB, Burr WE, Chen L (2010) Recommendation for Password-Based Key Derivation, Part 1: Storage Applications. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-132. https://doi.org/10.6028/NIST.SP.800-132

SP 800-135 Dang QH (2011) Recommendation for Existing Application-Specific Key Derivation Functions. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-135, Rev. 1. https://doi.org/10.6028/NIST.SP.800-135r1

SP 800-185 Kelsey, J, Chang, S., Perlner, R (2016) SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-185. https://doi.org/10.6028/NIST.SP.800-185.

A revision was made in 2019 with the following changes:

Added: identity authentication, KMAC. Removed: full-entropy, key update, and non-repudiation.

Removed: DLC and IFC.

Last para.: The example has been expanded.

Para. 3, lines 3-4: Inserted a parenthetical example.

Bullet 4: Added KMAC, as specified in SP 800-185. Also added text introducing the remainder of Section 6.

Last paragraph: Removed the last four lines.

Revision 2 was made in 2020:

Section 6.2 is now an introductory section for key derivation that includes a list of inputs that could be used for key derivation and a discussion of key-derivation methods.

(New) Section 6.2.2 (old Section 6.4): Added a 4th bullet about concatenating multiple keys.

a. The notation for the other data items has been changed from Vᵢ to Dᵢ to avoid a conflict with the use of Vᵢ in Section 3.4.

b. Additional discussion on combining key components has been added. c. Methods 2 and 3 from the previous version have been combined into the new Method 2. d. A new method using HMAC has been added as (a new) Method 3. e. Guidance for using each method has been further clarified.