NIST SP 800-57: Recommendation for Key Management

During my post of ‘Clarifying Enterprise Implications‘, I considered how QKD would influence current key maintenance. This NIST SP article will help me understand the concepts involved in key maintenance, and whether it is a suitable project focus.

**This blog has been updated as the publication that I was using was out of date. The updated information is sourced from NIST SP 800-57 Part 1, Revision 4. **

An important item to note before I extrapolate certain information from the article, is that NIST Recommendations are designed to provide a “minimum level of security for U.S. government systems” (section 1.4, part 1), which means that this information will not provide an accurate example for key maintenance in New Zealand enterprises. It will however, provide me with more knowledge of what practices are involved in key maintenance.

This blog only contains information from section 5 of the NIST SP 800-57, and I will write further blogs based upon other relevant information contained in the NIST publication.

From section 5: General Key Management Guidance

  • A key should be used for only one purpose
    • Using the same key for multiple uses may weaken security
    • Limiting a key to one purpose reduces the potential destruction that could occur if the key were to become compromised.
    • Some uses of keys interfere with each other. E.g. A key shouldn’t be used for key transport and as a digital signature.
    • (This does not include multi-service keys such as one that provides encryption and authentication of data during the same use.)
  • There should exist well-defined lifetimes for each key, dependent upon various factors such as amount of data encrypted by a single key, the key’s algorithm, the sensitivity of the data accessible by the key.
  • The risk involved with key exposure should be determined, and various factors should be taken into account in order to minimize the risk. NIST SP 800-57 contains the following factors:
    • Strength of cryptographic mechanisms
    • The environment in which the key is utilized
    • The security life of the data
    • The transaction number or volume of information flow that is using a single key
    • The process of key updates and key derivation
    • The methods involved in re-keying
    • The mechanisms/technology involved for creating, holding, updating keys
    • The security function which includes data encryption, key production, and key protection.
    • Number of nodes in a network that share a common key
    • Number of copies of a key and their distribution
    • Personnel turnover
    • Threat from adversaries and their perceived technical capabilities and financial resources
    • Threat to information from new and disruptive technologies (e.g. quantum computers)
  • The key’s operation should be well defined in regards to whether it is used for encryption exchangeable data or whether it is being used to encrypt stored data.
  • The cost involved with replacing or cancelling a key needs to be considered.
  • The differences of symmetric and asymmetric keys should be considered, as this will determine which key will be implemented.


The NIST SP 800-57 provides the following table describing their recommended cryptoperiods for a range of key types:

Cryptoperiods for key types _Part ICryptoperiods for key types _Part II

Most keys appear to have a lifetime of less than two years, with the longest lifetime being less than five years.

The article also provides the following procedures that may minimize the likelihood of a key from being compromised:

  • Limit time that symmetric or private key is in plaintext
  • Prevent human view of the plaintext of the private and symmetric keys
  • Restricting plaintext symmetric and private keys to physically protected containers
  • Use regular integrity checks to ensure that the key or its associated data hasn’t been compromised
  • Employ the use of key confirmation
  • Employ an accountability system that keeps track of access to plaintext form of symmetric and private keys
  • Ensure that there are regular cryptographic integrity checks on the key
  • Use trusted timestamps for signed data
  • Destroy the key as soon as it is no longer required


The article also entails cryptographic algorithms and key size selection. It provides the following table that provides algorithm security lifetimes and the corresponding symmetric key algorithms.
Comparable strengths of keys
-The security strength column denotes an estimated maximum strength, in units of bits. -The orange-filled cells are keys that are considered no longer approved for Federal government information, which does not apply to my project. The yellow cells are certain key strengths for the FFC and IFC algorithms that NIST does not include in its standards. This also does not apply to my project.
-The FFC (finite field cryptography) column provides a minimum size for keys, where L is the public key length, and N is the private key length.
-The fourth column provides a value based upon integer-factorization cryptography (IFC), where k is considered to be the key size.
-The final column provides a range of values of key size for elliptic curve cryptography (ECC).

The following tables are NIST’s acceptable time frames for the keys based upon their security strength.
Security strength time frames _Part ISecurity strength time frames _Part II

Note, these tables are based upon the latest publication, which was published in 2016.

Their nomenclature within the table has the following definitions:
Applying: Data is being encrypted
Processing: Data is being decrypted
Disallowed: The key length does not fulfill the NIST standards for suitability of application on the data
Legacy-Use: The length is suitable for processing encrypted data
Acceptable: The length is suitable for cryptographic application upon data as the key has no known insecurities.

This data, although based upon the NIST standards, does provide me with a general time frame for keys in regards to their security strength.


This section of the publication has provided me with three main focuses for key maintenance; the purpose of the key, its expected security lifetime, and minimization of risks that may lead to key compromise.

When I have completed more research upon quantum keys, I can compare this information as to how it applies to quantum keys and their distribution.


Barker et al.(March 2007) Recommendation for Key Management-Part 1: General (Revised), NIST Special Publication 800-57.

Barker et al. (January 2016) Recommendation for Key Management-Part 1: General (Revised), NIST Special Publication 800-57. 



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s