NIST SP 800-57pt1r6 ipd: Recommendation for Key Management: Part 1 – General

NIST Special Publication 800 NIST SP 800-57pt1r6 ipd

Recommendation for Key Management Part 1 — General Initial Public Draft Elaine Barker William Barker

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

NIST Special Publication 800 NIST SP 800-57pt1r6 ipd

Recommendation for Key Management Part 1 — General Initial Public Draft Elaine Barker

Computer Security Division Information Technology Laboratory

William Barker

Information Technology Laboratory; Strativia LLC*

*Former Strativia employee; some work for this publication was done while at Strativia

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-57pt1r6.ipd December 2025

U.S. Department of Commerce Howard Lutnick, Secretary National Institute of Standards and Technology Craig Burkhardt, Acting Under Secretary of Commerce for Standards and Technology and Acting NIST Director

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

Certain 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 YYYY-MM-DD [Will be added to final publication.] Supersedes NIST Series XXX (Month Year) DOI [Will be added to final publication, if applicable.] How to Cite this NIST Technical Series Publication Barker E, Barker W (2025) Recommendation for Key Management: Part 1 — General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-57pt1r6 ipd. https://doi.org/10.6028/NIST.SP.800-57pt1r6.ipd Author ORCID iDs Elaine Barker: 0000-0003-0454-0461 William Barker: 0000-0002-4113-8861 Public Comment Period December 5, 2025 – February 5, 2026

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

Submit Comments keymanagement@nist.gov National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Additional Information Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/57/pt1/r6/ipd, including related content, potential updates, and document history. All comments are subject to release under the Freedom of Information Act (FOIA).

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1

Abstract

2 3 4 5 6 7 8 9 10

This recommendation provides cryptographic key-management guidelines in three parts. Part 1 provides general guidelines and best practices for the management of cryptographic keying material, including definitions for the security services that may be provided when using cryptography and the algorithms and key types that may be employed, specifications for the protection that each type of key and other cryptographic information requires and methods for providing this protection, discussions about the functions involved in key management, and discussions about a variety of key-management issues to be addressed when using cryptography. Part 2 provides guidance on policy and security planning requirements for U.S. Government agencies. Part 3 provides guidelines for using the cryptographic features of current systems.

11

Keywords

12 13 14 15 16

archive; authentication; authorization; availability; backup; compromise; confidentiality; cryptographic key; cryptographic module; digital signature; eXtendable-Output Function; hash function; hashing method; key agreement; key management; key recovery; keying material; key transport; private key; public key; quantum-resistant; secret key; security category; security strength; trust anchor.

17

Reports on Computer Systems Technology

18 19 20 21 22 23 24 25 26 27

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.

28

i

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

29

Recommendation for Key Management Part 1 — General

Note to Reviewers

30 31

1. Ascon, as specified in SP 800-232, and the new quantum-resistant algorithms specified in FIPS 203, 204, and 205 have been included.

32

2. The keys used for both key establishment and key storage are now discussed separately.

33 34

3. The security categories used in the PQC competition have been included, along with the quantum-resistant algorithms.

35 36

4. The time frames for algorithm approval status have been removed and replaced with references to SP 800-131A.

37

5. A section has been added to discuss keying material storage and mechanisms.

38

6. See Appendix F for a more complete list of changes.

39

ii

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

40

Call for Patent Claims

41 42 43 44 45 46

This public review includes a call for information on essential patent claims (claims whose use would be required for compliance with the guidance or requirements in this Information Technology Laboratory (ITL) draft publication). Such guidance and/or requirements may be directly stated in this ITL Publication or by reference to another publication. This call also includes disclosure, where known, of the existence of pending U.S. or foreign patent applications relating to this ITL draft publication and of any relevant unexpired U.S. or foreign patents.

47 48

ITL may require from the patent holder, or a party authorized to make assurances on its behalf, in written or electronic form, either:

49 50

a) assurance in the form of a general disclaimer to the effect that such party does not hold and does not currently intend holding any essential patent claim(s); or

51 52 53

b) assurance that a license to such essential patent claim(s) will be made available to applicants desiring to utilize the license for the purpose of complying with the guidance or requirements in this ITL draft publication either:

54 55

i.

under reasonable terms and conditions that are demonstrably free of any unfair discrimination; or

56 57

ii.

without compensation and under reasonable terms and conditions that are demonstrably free of any unfair discrimination.

58 59 60 61 62

Such assurance shall indicate that the patent holder (or third party authorized to make assurances on its behalf) will include in any documents transferring ownership of patents subject to the assurance, provisions sufficient to ensure that the commitments in the assurance are binding on the transferee, and that the transferee will similarly include appropriate provisions in the event of future transfers with the goal of binding each successor-in-interest.

63 64

The assurance shall also indicate that it is intended to be binding on successors-in-interest regardless of whether such provisions are included in the relevant transfer documents.

65

Such statements should be addressed to: keymanagement@nist.gov.

66

iii

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

67

Table of Contents

68

Executive Summary............................................................................................................................1

69

1. Introduction ...................................................................................................................................3

70 71 72 73 74 75

2. Security Services ............................................................................................................................8

76 77 78 79 80 81 82 83

3. Cryptographic Algorithms .............................................................................................................14

84 85 86 87 88

4. General Key-Management Guidelines ...........................................................................................17

89 90

4.1.1. Cryptographic Keys ..................................................................................................................... 17

91

4.1.2. Other Related Information ......................................................................................................... 21

92 93 94

4.3.1. Factors Affecting Cryptoperiods ................................................................................................. 23

95

4.3.2. Consequence Factors Affecting Cryptoperiods .......................................................................... 24

96

4.3.3. Other Factors Affecting Cryptoperiods ...................................................................................... 25

97

4.3.4. Asymmetric Key Usage Periods and Cryptoperiods ................................................................... 25

98

4.3.5. Symmetric Key Usage Periods and Cryptoperiods ..................................................................... 26

99

4.3.6. Cryptoperiod Recommendations for Specific Key Types ........................................................... 27

100 101

4.4.1. Assurance of Integrity (Integrity Protection).............................................................................. 40 iv

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

102

4.4.2. Assurance of Algorithm Parameter Validity ............................................................................... 40

103

4.4.3. Assurance of Public-Key Validity ................................................................................................ 41

104

4.4.4. Assurance of Private-Key Possession ......................................................................................... 41

105

4.4.5. Key Confirmation ........................................................................................................................ 41

106 107

4.5.1. Implications ................................................................................................................................ 42

108

4.5.2. Protective Measures................................................................................................................... 43

109 110

4.6.1. Cryptographic Algorithm Security Strengths .............................................................................. 45

111

4.6.2. Using Algorithm Suites and the Effective Security Strength ...................................................... 52

112

4.6.3. Projected Algorithm and Security Strength Approval Status ..................................................... 54

113

4.6.4. Transitioning to New Algorithms and Key Sizes in Systems ....................................................... 55

114

4.6.5. Decrease in Security Over Time ................................................................................................. 60

115

5. Protection Requirements for Key Information ...............................................................................63

116 117

5.1.1. Summary of Protection and Assurance Requirements for Cryptographic Keys......................... 64

118

5.1.2. Summary of Protection Requirements for Other Related Information ..................................... 71

119 120

5.2.1. Protection Mechanisms for Key Information in Transit ............................................................. 75

121

5.2.2. Protection Mechanisms for Key Information in Storage ............................................................ 78

122

5.2.3. Metadata for Keys ...................................................................................................................... 87

123

6. Key States and Transitions ............................................................................................................89

124 125 126 127 128 129

7. Key-Management Phases and Functions .......................................................................................97

130 131

7.1.1. Entity Registration Function ..................................................................................................... 100

132

7.1.2. System Initialization Function .................................................................................................. 100

133

7.1.3. Initialization Function ............................................................................................................... 101

134

7.1.4. Keying-Material Installation Function ...................................................................................... 101

135

7.1.5. Key-Establishment Function ..................................................................................................... 101

136

7.1.6. Key Registration Function......................................................................................................... 114

v

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

137 138

7.2.1. Normal Operational Storage Function ..................................................................................... 115

139

7.2.2. Continuity of Operations Function ........................................................................................... 116

140

7.2.3. Key Change Function ................................................................................................................ 119

141

7.2.4. Key Derivation Methods ........................................................................................................... 120

142 143

7.3.1. Key Archive and Key Recovery Functions ................................................................................. 121

144

7.3.2. Entity De-Registration Function ............................................................................................... 125

145

7.3.3. Key De-Registration Function ................................................................................................... 125

146

7.3.4. Key Destruction Function ......................................................................................................... 126

147

7.3.5. Key Revocation Function .......................................................................................................... 126

148 149

8. Additional Considerations .......................................................................................................... 129

150 151 152

8.2.1. Key Inventories ......................................................................................................................... 130

153

8.2.2. Certificate Inventories .............................................................................................................. 130

154 155 156 157

8.5.1. Backed Up and Archived Key .................................................................................................... 134

158

8.5.2. Key Recovery ............................................................................................................................ 134

159

8.5.3. System Redundancy/Contingency Planning ............................................................................. 136

160

8.5.4. Compromise Recovery.............................................................................................................. 138

161

References..................................................................................................................................... 140

162 163

Appendix A. Cryptographic and Non-Cryptographic Integrity and Source Authentication Mechanisms ...................................................................................................................................................... 147

164

Appendix B. Key Recovery .............................................................................................................. 150

165 166

B.1.1. Recovery From Stored Keying Material.................................................................................... 151

167

B.1.2. Recovery by Reconstruction of Keying Material ...................................................................... 151

168

B.1.3. Conditions Under Which Keying Material Needs to be Recoverable....................................... 151

169

B.1.4. Key-Recovery Systems.............................................................................................................. 152

170

B.1.5. Key-Recovery Policy ................................................................................................................. 153

171

vi

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

172

B.2.1. Private Signature Key ............................................................................................................... 154

173

B.2.2. Public Signature-Verification Key ............................................................................................. 155

174 175

B.3.1. Symmetric Authentication Key................................................................................................. 155

176

B.3.2. Authentication (Asymmetric) Key Pair ..................................................................................... 156

177 178 179 180

B.6.1. Symmetric Key-Wrapping Key .................................................................................................. 157

181

B.6.2. Key-Transport Key Pair ............................................................................................................. 157

182

B.6.3. Symmetric Key-Agreement Key................................................................................................ 158

183

B.6.4. Static Key-Agreement Key Pair ................................................................................................. 158

184

B.6.5. Ephemeral Key-Agreement Key Pair ........................................................................................ 159

185

B.6.6. Static Encapsulation/Decapsulation Key Pair ........................................................................... 160

186

B.6.7. Ephemeral Encapsulation/Decapsulation Key Pair .................................................................. 160

187 188

B.7.1. Encryption/Decryption of Data in Transit ................................................................................ 161

189

B.7.2. B.7.2

Encryption/Decryption of Data at Rest ...................................................................... 161

190 191

B.8.1. Symmetric Key Wrapping/Unwrapping Key ............................................................................. 163

192

B.8.2. Asymmetric Key Encryption/Decryption Key Pair .................................................................... 163

193

B.8.3. Encapsulation/Decapsulation Key Pair..................................................................................... 164

194 195

B.9.1. Symmetric Authorization Key................................................................................................... 164

196

B.9.2. Authorization Key Pair .............................................................................................................. 164

197 198

B.10.1. Algorithm Parameters ............................................................................................................ 165

199

B.10.2. Initialization Vector (IV).......................................................................................................... 165

200

B.10.3. Shared Secret ......................................................................................................................... 165

201

B.10.4. Seed ........................................................................................................................................ 166

202

B.10.5. Other Public and Secret Information ..................................................................................... 166

203

B.10.6. Intermediate Results .............................................................................................................. 166

204

B.10.7. Key-Control Information/Metadata ....................................................................................... 166

205

B.10.8. Random Numbers .................................................................................................................. 166

206

B.10.9. Password ................................................................................................................................ 166

vii

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

207

B.10.10. Audit Information ................................................................................................................. 167

208

Appendix C. Security Strength Categories for Post-Quantum Algorithms ......................................... 168

209

Appendix D. List of Abbreviations and Acronyms ............................................................................ 170

210

Appendix E. Glossary...................................................................................................................... 174

211

Appendix F. Change Log ................................................................................................................. 186

212

List of Tables

213

Table 1. Suggested cryptoperiods for key types.................................................................................39

214

Table 2: Security Strength Categories for Post-quantum Algorithms ..................................................46

215

Table 3: Security strengths of symmetric block cipher algorithms ......................................................47

216

Table 4: Security strengths of classical asymmetric-key algorithms ....................................................48

217

Table 5:Security strengths of quantum-resistant asymmetric-key algorithms.....................................49

218

Table 6: Maximum security strengths for hash methods and hash-based functions ............................51

219

Table 8. Protection requirements for cryptographic keys ..................................................................65

220

Table 9. Protection requirements for other related information ........................................................72

221

Table 10. Backup of keys ................................................................................................................ 117

222

Table 11. Backup of other related information ................................................................................ 118

223

Table 12. Archive of keys ................................................................................................................ 122

224

Table 13. Archive of other related information ............................................................................... 124

225

List of Figures

226

Figure 1. Symmetric-key cryptoperiod ..............................................................................................27

227

Figure 2. Algorithm originator-usage period example ........................................................................56

228

Figure 3. Key state and transition example .......................................................................................89

229

Figure 4. Key-management phases ...................................................................................................98

230

Figure 5. Key-management states and phases ...................................................................................99

231

Figure 6: Example of a tree of keys in storage ................................................................................. 162

232

viii

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

233

Acknowledgments

234 235 236 237 238 239

The National Institute of Standards and Technology (NIST) gratefully acknowledges and appreciates the contributions of previous authors on the many security issues associated with this document: William Burr and Timothy Polk from NIST, Miles Smid from Orion Security, and Lydia Zieglar from the National Security Agency. NIST also thanks the many contributions from the public and private sectors whose thoughtful and constructive comments improved the quality and usefulness of this publication.

240

ix

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

241

Executive Summary

242 243 244 245 246

Cryptography is used to secure communications over networks, to protect information stored in databases, and for many other critical applications. Cryptographic keys play an important part in the operation of cryptography. These keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration.

247 248 249 250 251

The proper management of cryptographic keys is essential to the effective use of cryptography for security. Poor key management may easily compromise strong algorithms. This recommendation provides guidelines for the management of a cryptographic key throughout its life cycle, including its secure generation, storage, distribution, use, and destruction.

252 253 254 255 256

Ultimately, the security of information protected by cryptography directly depends on the strength of the keys, the effectiveness of cryptographic mechanisms and protocols associated with the keys, and the protection provided to the keys. Secret and private keys need to be protected against unauthorized disclosure, and all keys need to be protected against modification.

257 258 259 260 261

Cryptographic keys are used across a broad range of systems and applications in enterprises, many of which are managed by individuals who may not have expertise in key management. Consequently, organizations must ensure that clear guidance and oversight is provided for the proper management of keys, as well as controls to ensure that the guidance is being followed and implemented.

262 263 264 265 266

Organizations and developers are presented with many choices in their use of cryptographic mechanisms. Inappropriate choices may result in an illusion of security but with little or no real security for the protocol or application. This recommendation provides background information and establishes a framework to support appropriate decisions when selecting and using cryptographic mechanisms.

267 268 269 270 271 272

Cryptographic modules are used to perform cryptographic operations using these keys. This recommendation does not address the implementation details for cryptographic modules that may be used to achieve the security requirements identified herein. These details are addressed in Federal Information Processing Standards (FIPS) Publication 140 [FIPS 140-3] and its associated implementation guidance and derived test requirements, which are available at https://csrc.nist.gov/projects/cmvp.

273

This recommendation is divided into three parts:

274

•

Part 1 — General contains basic key-management guidelines

275 276

•

Part 2 — Best Practices for Key Management Organizations provides a framework and general guidance to support establishing cryptographic key management.

1

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

277 278 279

•

Recommendation for Key Management Part 1 — General

Part 3 — Application-Specific Key Management Guidance addresses the keymanagement issues associated with currently available implementations that use cryptography.

280

2

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

281

1. Introduction

282 283 284 285

The use of cryptographic mechanisms is one of the strongest ways to provide security services for communications, data storage, and other applications. The National Institute of Standards and Technology (NIST) publishes FIPS and NIST Special Publications (SPs) that specify cryptographic techniques for protecting controlled unclassified information (CUI). 1

286 287 288 289 290 291 292 293 294

Since NIST published the Data Encryption Standard (DES) in 1977, the suite of approved standardized algorithms has grown. New classes of algorithms have been added, such as secure hash functions, key-derivation functions, and asymmetric quantum-resistant algorithms. The suite of algorithms provides different levels of cryptographic strength through a variety of key lengths. The algorithms may be combined in many ways to support increasingly complex protocols and applications. This NIST recommendation applies to federal agencies that use cryptography to protect CUI. On a voluntary basis, this recommendation may also be followed by other organizations that want to implement sound security principles in their computer systems.

295 296 297 298 299 300 301 302 303

The proper management of cryptographic keys and other key information is essential to the effective use of cryptography for security. Cryptographic keys are analogous to the combination of a safe. If an adversary knows the combination, the strongest safe provides no security against penetration. Similarly, poor key management may easily compromise strong algorithms. Ultimately, the security of the information protected by cryptography directly depends on the strength of the keys, the effectiveness of the mechanisms and protocols associated with the keys, and the protection afforded to the keys. Cryptography can be rendered ineffective by weak implementations, inappropriate algorithm pairing, poor physical security, and weak (i.e., vulnerable) protocols.

304 305 306 307 308 309

Key management is the process of managing a key throughout its life cycle, including its secure generation, storage, distribution, use, and destruction. Keys may be managed manually, but an automated system is often required to oversee, automate, and secure the key-management process. An automated system that performs key management is commonly known as a (cryptographic) key-management system (see [SP 800-130] and [SP 800-152].)

310 311 312 313 314 315 316 317 318 319

NIST-approved cryptographic techniques are periodically reassessed for their continued effectiveness. The algorithms specified in NIST standards (e.g., AES, SHA-2, and ECDSA) and the cryptographic modules in which they reside have required conformance tests. Accredited laboratories perform these tests on vendor implementations that claim conformance to the standards. Vendors are required to modify nonconforming implementations so that they meet all applicable requirements. Users of validated implementations can have a high degree of confidence that validated implementations conform to the standards. If any technique is found to be inadequate for the continued protection of government information, the NIST standard is revised or discontinued. Since 1977, NIST has developed a cryptographic “toolkit” of NIST standards2 that form a basis for the implementation of approved cryptography. Part 1 CUI was previously referred to as “sensitive but unclassified information.”

2 The toolkit consists of publications specifying algorithms and guidance for their use rather than software code.

3

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

320 321 322

1 references many of those standards and provides guidelines for how they may be properly used to protect CUI. The process for developing NIST standards is documented in [NIST IR 7977].

323

1.1. Purpose

324 325 326 327 328

Organizations and developers are presented with many new choices in their use of cryptographic mechanisms. Inappropriate choices may result in little or no real security for the protocol or application. This recommendation provides background information and establishes frameworks to support appropriate decisions when selecting and using cryptographic mechanisms.

329

1.2. Audience

330 331 332 333

The audiences for this recommendation include system and application owners and managers, cryptographic module developers, protocol developers, and system administrators. The recommendation is provided in three parts, which have been tailored to specific audiences:

334 335 336 337 338 339 340 341 342

1. Part 1 (i.e., this document) provides general key-management guidelines that are intended to be useful to both system developers and system administrators. 3 Cryptographic module developers may benefit by acquiring a greater understanding of the key-management features that are required to support specific applications. Protocol developers may identify key-management characteristics associated with specific suites of algorithms and acquire a greater understanding of the security services provided by those algorithms. System administrators may use Part 1 and Part 3 to assist in determining configuration settings that would be most appropriate for their systems.

343 344 345 346

2. Part 2 [SP 800-57p2] helps system and application owners (e.g., the information security group within the organization) identify appropriate organizational keymanagement infrastructures, establish organizational key-management policies, and specify organizational key-management practices and plans.

347 348 349 350 351

3. Part 3 [SP 800-57p3] addresses the key-management issues associated with currently available cryptographic mechanisms. It is intended to provide guidelines for system installers, system administrators, and end users of existing key-management infrastructures, protocols, and other applications as well as the people making purchasing decisions for new systems using currently available technology.

352 353 354

Although some background information and rationale are provided for context and to support the recommendations, this document assumes that the reader has a basic understanding of cryptography. For background material, readers may refer to a variety of

3 System administrators will require additional specific information when setting up their systems.

4

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

355 356

NIST and commercial publications, including [SP 800-175B], which recommendations for using cryptography and NIST’s cryptographic standards.

provides

357

1.3. Scope

358 359 360 361

Part 1 of this recommendation discusses cryptographic algorithms, infrastructures, protocols, implementations, applications, and the management thereof. All cryptographic algorithms currently approved by NIST for the protection of controlled unclassified information are within the scope of Part 1.

362 363 364

Part 1 focuses on issues involving the management of cryptographic keys: their generation, use, and eventual destruction. Related topics (such as, algorithm selection and appropriate key length, cryptographic policy, and cryptographic module selection) are also included.

365 366 367 368 369 370 371

This recommendation does not address the implementation details for cryptographic modules that may be used to achieve the identified security requirements, which are provided in [FIPS 140-3], CMVP implementation guidance [IGD_B], and derived test requirements [SP 800-140]. Moreover, this recommendation does not address the requirements or procedures for operating a key archive or backup capability other than discussing the types of keying material that are appropriate to back up or include in an archive and the protection to be provided to the keying material.

372 373

This recommendation often uses “requirement” terms, which have the following meaning in this document:

374 375 376

1. Shall: This term is used to indicate a requirement of a FIPS or a requirement that must be fulfilled to claim conformance to this recommendation. Shall may be combined with not to become shall not.

377 378 379

2. Should: This term is used to indicate an important recommendation. Ignoring the recommendation could result in undesirable results. Should may be combined with not to become should not.

380

1.4. Preliminary Discussion of Terms

381 382 383 384

Part 1 of this recommendation uses several terms related to the management of cryptographic key information. While each of these terms is defined in Appendix E, it may be useful to compare these terms and show their relationships, since they will be used throughout the document:

385 386 387 388 389 390 391

•

A cryptographic key is a parameter used in conjunction with a cryptographic algorithm that determines its operation in such a way that an entity with knowledge of the key can reproduce, reverse, or verify the operation, while an entity without knowledge of the key cannot. Examples include a symmetric key used with AES to encrypt plaintext data and decrypt ciphertext data, a private signature key used with a digital signature algorithm to generate a digital signature, or a public signature-verification key used with a digital signature algorithm to verify a digital signature.

5

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

392 393 394 395 396 397 398 399

Recommendation for Key Management Part 1 — General

Keys are owned and used by entities (e.g., individuals, organizations, devices, or processes) that interact with other entities to conduct business. In the case of nonhuman owners (i.e., an organization, device, or process), the owner is represented or sponsored by one or more humans. For example, if the owner is an organization, then several humans may be authorized to use the key, and the humans may be said to represent the organization when conducting its business. A device or process may own and use the key, but a human sponsor is responsible for managing the key (e.g., generating or replacing the key when required).

400 401 402

•

Keying material includes a cryptographic key and other material (e.g., an Initialization Vector or algorithm parameters) to be used during the execution of a cryptographic algorithm.

403 404 405

•

Metadata is the information associated with a key that describes its specific characteristics, constraints, acceptable uses, ownership, and other details. Portions of the metadata may be secret (e.g., the identity of the key’s owner, in some cases).

406 407

•

Key information is information about a particular key that includes all of the keying material associated with that key and associated metadata related to that key.

408 409 410

Symmetric keys and the private keys of asymmetric-key (public-key) algorithms require confidentiality protection, and some metadata elements may also require this protection. All key information requires integrity protection.

411

1.5. Content and Organization

412

This document is organized as follows:

413

•

Section 1, Introduction, establishes the purpose, scope, and intended audience.

414 415

•

Section 2, Security Services, defines the security services that may be provided using cryptographic mechanisms.

416 417 418

•

Section 3, Cryptographic Algorithms, provides background information regarding the approved cryptographic algorithms that generate and use cryptographic keying material.

419 420 421 422 423 424 425

•

Section 4, General Key-Management Guidelines, classifies the different types of keys and other key information according to their uses, discusses cryptoperiods and recommends appropriate cryptoperiods for each key type, provides recommendations and requirements for other keying material, introduces the concept of assurance of algorithm-parameter and public-key validity, discusses the implications of a key compromise, and provides guidelines for cryptographic algorithm and key-size selection, implementation, and replacement.

426 427 428 429

•

Section 5, Protection Requirements for Key Information, specifies the protection that each type of key information requires and identifies methods for providing this protection. These protection requirements should be of particular interest to cryptographic module vendors and application implementers. 6

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

430 431

•

Section 6, Key State and Transitions, identifies the states in which a cryptographic key may exist during its lifetime.

432 433 434 435

•

Section 7, Key-Management Phases and Functions, identifies four phases and a multitude of functions involved in key management. This section should be of particular interest to cryptographic module vendors and developers of cryptographic infrastructure services.

436 437

•

Section 8, Additional Considerations, discusses access control, identity authentication, inventory management, accountability, audit, and survivability.

438

•

The References list the sources cited in this document.

439 440 441

•

Appendix A, Cryptographic and Non-Cryptographic Integrity and SourceAuthentication Mechanisms, provides supplemental information about integrity and source-authentication services.

442 443

•

Appendix B, Key Recovery, provides additional information about recovering keys from key backups and archives.

444 445 446

•

Appendix C, Security Strength Categories for Post-Quantum Algorithms, provides a collection of broad categories that have been developed to address uncertainties in estimating the security strengths of post-quantum cryptosystems.

447 448

•

Appendix D, List of Abbreviations and Acronyms, includes all of the abbreviations and acronyms used in this document.

449

•

Appendix E, Glossary, provides definitions for the terms used in this document.4

450 451

•

Appendix F, Change Log, contains a history of the changes made since the previously published version of this document (i.e., Revision 5).

452

4 Terms and definitions may be written differently in other documents.

7

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

453

2. Security Services

454 455 456 457 458 459 460 461

Cryptography may be used to provide or support several basic security services: confidentiality, identity authentication, integrity authentication, source authentication, authorization, and non-repudiation. These services may also be required to protect a key and information related to that key. In addition, there are other cryptographic and noncryptographic mechanisms that are used to support these security services. In general, a single cryptographic mechanism may provide more than one service (e.g., the use of digital signatures can provide integrity authentication and source authentication) but not all services.

462

2.1. Confidentiality

463 464 465 466 467 468 469 470

Confidentiality is the property whereby information is not disclosed to unauthorized parties; secrecy and privacy are terms that are often used synonymously with confidentiality. Confidentiality can be obtained using encryption to render the information unintelligible except by an authorized party that uses an appropriate key to decrypt the encrypted information. For encryption to provide confidentiality, the cryptographic algorithm used for encryption and its mode of operation must be designed and implemented so that an unauthorized party cannot determine the decryption key associated with the encryption or derive the plaintext directly without using the key.

471

2.2. Data Integrity

472 473 474 475 476 477 478 479 480

Data integrity is a property whereby data has not been modified in an unauthorized manner since it was created, transmitted, or stored. Modification includes the insertion, deletion, and substitution of data. Cryptographic mechanisms, such as message authentication codes (MACs) or digital signatures, can be used to detect (with a high probability) both accidental modifications (e.g., modifications that sometimes occur during noisy transmissions or by hardware memory failures) and deliberate modifications by an adversary. Non-cryptographic mechanisms are also often used to detect accidental modifications but cannot be relied upon to detect deliberate modifications. A more detailed treatment of this subject is provided in Appendix A.

481 482 483

In this recommendation, the statement that a cryptographic algorithm “provides data integrity” means that the algorithm can be used to detect unauthorized modifications. Authenticating integrity is discussed in the next section.

484

2.3. Authentication

485

Three types of authentication services can be provided using cryptography:

486 487

1. An identity authentication service is used to provide assurance of the identity of an entity interacting with a system.

8

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

488 489

2. An integrity authentication service is used to verify that data has not been modified (i.e., this service provides integrity protection).

490 491

3. A source authentication service is used to verify the identity of the entity that created and/or sent information.

492 493 494

Source authentication and identity authentication are very similar but have different purposes. For example, source authentication is concerned with who originated a message, whereas identity authentication is used to gain access to some service.

495 496 497

Several cryptographic mechanisms may be used to provide authentication services. Most commonly, digital signatures or MACs are used to provide authentication; some keyestablishment techniques may also provide authentication.

498 499 500

When multiple individuals are permitted to share the same identity or source authentication information (e.g., a password or cryptographic key), it is sometimes called role-based authentication.

501

2.4. Authorization

502 503 504 505 506 507 508 509 510

Authorization is concerned with providing an official sanction or permission to perform a function or activity (e.g., to access a document or access a room). Authorization is considered to be a security service that is often supported by a cryptographic service. Normally, authorization is granted only after the execution of a successful identity authentication service. A non-cryptographic analog of the interaction between identity authentication and authorization is the examination of an individual’s credentials to establish their identity. After verifying the individual’s identity and authorization to access some resource (e.g., a locked room), the individual is often provided with a key (e.g., an authorization key) or password that will allow access to that resource.

511 512 513

Identity authentication can also be used to authorize a role (e.g., a system administrator or audit role) rather than identify an individual. Once authenticated for a role, an entity is authorized for all of the privileges associated with that role.

514

2.5. Non-Repudiation

515 516 517 518 519 520 521

In key management, non-repudiation is a term associated with digital signature keys and digital certificates that bind the name of the certificate subject to a public key. When nonrepudiation is indicated for a digital signature key, it means that the signatures created by that key not only support the usual integrity and source authentication services of digital signatures but may also (depending on the context of the signature) indicate commitment by the certificate subject in the same sense that a handwritten signature on a document may indicate commitment to a contract.

522 523

Non-repudiation in a key-management context is not the same as non-repudiation in a legal context. Cryptographic mechanisms can be used to provide evidence of the source of

9

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

524 525

information, but other elements are involved in making a legal determination of nonrepudiation.

526

2.6. Support Services

527 528 529 530 531 532 533 534

The basic cryptographic security services discussed in the previous subsections often require other supporting services. For example, cryptographic services often require the use of keyestablishment and random number generation services. Key establishment is the process by which cryptographic keys are securely established among entities using manual transport methods (e.g., using key loaders), automated methods (e.g., key-transport and/or keyagreement protocols), or a combination of automated and manual methods. Random numbers are needed during the generation of cryptographic keys, challenge values, and nonces [SP 800-175B].

535 536 537 538 539 540 541

When keying material and other data are no longer needed, there is often a requirement to destroy5 the keying material and other information. All copies of that information need to be destroyed by all entities privy to the information, whether in operational, backup, or archive storage; on key loaders; or printed on paper or other media. When developing or selecting a key-management capability, the method for destroying keying material and other information needs to be considered for each type of media used. [SP 800-88] provides guidelines for the sanitization of sensitive information.

542

2.7. Combining Services

543 544 545 546 547 548 549 550 551 552 553 554

In many applications, a combination of security services (e.g., confidentiality, integrity authentication, source authentication, and/or non-repudiation) is desired. Designers of secure systems often begin by considering which security services are needed to protect the information stored and processed by the system. After these services have been identified, the designer then considers what mechanisms will best provide these services. Not all mechanisms are cryptographic in nature. For example, physical security may be used to protect the confidentiality of certain types of data (e.g., by placing the data in a safe), and identification badges or biometric identification devices may be used for identity authentication. However, cryptographic mechanisms that consist of algorithms, keys, and other keying material often provide an additional, cost-effective means of protecting the security of information. This is particularly true in applications where the information would otherwise be exposed to unauthorized entities.

555 556

When properly implemented, some cryptographic algorithms provide multiple services. For example:

557 558

•

A MAC can provide both source and integrity authentication if the symmetric keys are unique to each pair of entities and known only by those entities (see [SP 800-175B]).

5 Other terms often used are delete, destroy, zeroize, and sanitize.

10

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

559 560

•

A digital signature algorithm can provide identity, integrity, and source authentication as well as non-repudiation (see [SP 800-175B]).

561 562 563

•

Certain modes of operation can provide confidentiality, integrity authentication, and source authentication when properly implemented. These modes should be specifically designed to provide these services.

564 565 566 567 568 569 570 571 572 573 574 575 576

However, different algorithms and procedures typically need to be employed to provide all of the desired services. For example, consider a system in which the secure exchange of information between pairs of entities is needed. Some of the exchanged information requires only integrity protection, while other information requires both integrity and confidentiality protection. Each entity that participates in the information exchange must also know the identity of the other entity. The designers of this example system decide that a public-key infrastructure (PKI) needs to be established, and each individual who wants to communicate securely is required to obtain the necessary public-key certificates after physically proving their identity. A PKI includes one or more certification authorities (CAs) that are responsible for creating certificates and usually at least one registration authority (RA) associated with each CA. The RA is responsible for confirming the identities of entities requesting certificates. The identity-proving process requires the presentation of proper credentials, such as a driver’s license, passport, or birth certificate.

577 578

Two types of public-key certificates are commonly used: certificates used for digital signatures and certificates used for key establishment.

579 580 581 582 583 584 585 586 587

1. To obtain a digital signature certificate, an individual generates a pair of keys for a specific digital signature algorithm (e.g., RSA, ECDSA, or ML-DSA); that individual is the owner of the key pair. The key pair consists of a public key and a private key that correspond to each other and can be used only with the specific algorithm. The public key of the key pair is included in the certificate along with an identifier to be used by the key-pair owner and other information. The certificate is digitally signed by a CA using a digital signature private key owned by the CA, and the certificate is provided to the key-pair owner, deposited in a repository, or both. The private key remains under the sole control of the owner (i.e., the private key is kept secret).

588 589

When using digital signature certificates, one entity (i.e., a signatory) signs data using the private key and sends the signed data to an intended recipient. The recipient:

590 591

o Obtains the signatory’s public-key certificate (e.g., from the recipient or a repository),

592 593

o Verifies the certificate using the CA’s public key that corresponds to the private key used to sign the certificate, and then

594 595

o Uses the public key in the certificate (i.e., the public key corresponding to the private key used by the signatory) to verify the signature on the received data.

596 597

By using this process, the recipient obtains assurances of both the integrity and the source of the received data using a digital signature algorithm.

11

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

598 599 600 601

2. To obtain a certificate for key establishment, a key pair needs to be generated for a specific key-establishment algorithm (e.g., RSA, Diffie-Hellman, or ML-KEM). As in the case of digital signatures, the public key is placed in a certificate signed by a CA, and the private key is kept secret by the key-pair owner.

602 603

Three methods of key establishment employing certificates are used: key agreement, key transport, and key encapsulation (see [SP 800-175B]).

604 605 606 607 608

o Key agreement requires that when two entities wish to communicate, they need to exchange information (e.g., their key-establishment certificates containing their public keys and possibly other information) that allows both entities to generate the same keys without actually transmitting the keys between them.

609 610 611 612 613

o Key transport requires that one entity (i.e., the sender) select one or more keys to be sent to the other entity (i.e., the intended receiver) and encrypt them using the intended receiver’s certified public key before sending the encrypted key (i.e., the ciphertext) to the receiver for decryption. The originally generated key is retained by the sender.

614 615 616 617 618 619 620

o Key encapsulation requires that an encapsulating entity (i.e., the sender) generate a shared secret key and ciphertext using the intended receiver’s certified public key and a newly generated random value. The ciphertext is sent to the intended receiver for decapsulation, and the shared secret key is retained by the encapsulating sender. The receiver uses the ciphertext and its private key that corresponds to the certified public key to recover the same shared secret key retained by the encapsulating sender.

621 622 623 624 625 626 627

The key-establishment certificates are checked by verifying the CA’s signature on the certificate before using the agreed-upon, transported, or decapsulated keys. These keys can be used with a symmetric algorithm for encryption or message authentication to provide confidentiality or integrity protection for transmitted data. The receiver of the data protected by the symmetric keys has assurance that the data came from the other entity indicated by the public-key certificate (i.e., source authentication for the symmetric keys has been obtained).

628 629

These examples show how cryptographic algorithms may be used to support multiple security services. However, the security of such systems depends on many factors, including:

630 631

•

The strength of the individual’s credentials (e.g., a driver’s license, passport, or birth certificate) and the identity-authentication process;

632

•

The strength of the cryptographic algorithms used;

633

•

The degree of trust placed in the RA and CA;

634

•

The strength of the key-establishment protocols; and

635 636

•

The care taken by the users when generating their keys and protecting them from unauthorized use.

12

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

637 638 639 640 641

Recommendation for Key Management Part 1 — General

Therefore, designing a security system that provides the desired security services by making use of cryptographic algorithms and sound key-management techniques also requires careful consideration of all factors and risks. The design and implementation of such systems should be performed by analysts who have the necessary skills and expertise to effectively consider and address these factors and risks.

642

13

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

643

3. Cryptographic Algorithms

644 645 646 647 648 649 650

FIPS-approved and NIST-recommended cryptographic algorithms shall be used whenever cryptographic services are required. These approved algorithms have undergone an intensive security analysis prior to their approval and continue to be examined to ensure that they provide adequate security. Most cryptographic algorithms require cryptographic keys and other keying material. In some cases, an algorithm may be strengthened by increasing the key size used. Part 1 advises the users of cryptographic mechanisms on the appropriate choices of algorithms and key sizes.

651 652 653 654 655 656

Important note: Cryptanalytic algorithms (e.g., Shor’s algorithms running on future quantum computers) are projected to defeat the security provided by classical approved asymmetric algorithms (i.e., RSA, ECDSA and ECDH). A transition to quantum-resistant algorithms is underway. See https://csrc.nist.gov/projects/post-quantum-cryptography for the status of this effort.

657 658 659 660

This section describes the approved cryptographic algorithms that provide security services, such as confidentiality, identity authentication, integrity authentication, and source authentication. These services may be fulfilled using several different algorithms, although a single algorithm may often be used to provide multiple services (see [SP 800-175B]).

661 662 663 664

There are three basic classes of approved cryptographic algorithms: cryptographic hashing methods (see Sec. 3.1), symmetric-key algorithms (see Sec. 3.2), and asymmetric-key algorithms (see Sec. 3.3). Any keys required for using these algorithms must be generated using random bit generators (RBGs) (see Sec. 3.4).

665

3.1. Cryptographic Hashing Methods

666 667 668 669 670

In cryptography, hashing is the process of using an input bit string of arbitrary length to produce an output with a given length, which is referred to as the “hash value.” 6 Cryptographic hashing methods do not require keys for their basic operation. Two categories of hashing methods have been approved: cryptographic hash functions and eXtendableOutput Functions (XOFs).

671 672 673 674 675

A cryptographic hash function is a cryptographic primitive that produces a fixed-length output that is a condensed representation of its input (e.g., a message or other data). The number of output bits is determined by the design of the hash function. The approved hash functions are defined in [FIPS 180], [FIPS 202], and [SP 800-232]. Additionally, [SP 800-175B] provides a brief description of how a hash function works.

676 677 678

A XOF produces an output that can be extended to any desired length (e.g., the desired length is identified when requesting XOF execution). Approved XOFs for Federal Government use are specified in [FIPS 202] and [SP 800-232].

6 An alternative term for “hash value” is “message digest.”

14

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

679 680 681

With a well-designed hash function or XOF, it is not feasible to construct or find input that will produce a given hash value (i.e., pre-image resistance), nor is it feasible to find two inputs that produce the same hash value (i.e., collision resistance).

682 683 684

Many algorithms and schemes that provide a security service use a hash function or XOF as a component of the algorithm (i.e., use the hashing method as a building block for the algorithm or scheme) to:

685 686

•

Provide source and integrity authentication services using a MAC (see item 2 in Sec. 3.2),

687

•

Derive keys from pre-shared keys (see item 3 in Sec. 3.2),

688 689

•

Compress messages for digital signature generation and verification (see item 1 in Sec. 3.3),

690 691

•

Derive keys using asymmetric key-establishment algorithms (see item 2 in Sec. 3.3), or

692

•

Generate random numbers (see Sec. 3.4).

693

3.2. Symmetric-Key Algorithms

694 695 696 697 698 699 700

Symmetric-key algorithms (sometimes known as secret-key algorithms) transform data in a way that is fundamentally difficult to undo without knowledge of the secret key. The key is “symmetric” because the same key is used for a cryptographic operation and its inverse (e.g., for both encryption and decryption). Symmetric keys are often known by more than one entity. However, the key shall be generated using a random process and shall not be disclosed to entities that are not authorized to access the data protected by that algorithm and key.

701 702 703 704 705 706

Three classes of symmetric-key algorithms have been approved: those based on block cipher algorithms (e.g., AES, as specified in [FIPS 197]), those based on permutations (e.g., AsconAEAD128, as specified in [SP 800-232]), and those based on the use of a hash function or XOF (e.g., a keyed-hash MAC, as specified in [SP 800-224]). [SP 800-175B] provides discussions on each algorithm type as well as the modes of operation that are used with block cipher algorithms.

707

Symmetric-key algorithms may be used to:

708 709

•

Provide data confidentiality — The same key is used to encrypt and decrypt data (see [FIPS 197], [SP 800-38A], [SP 800-38C], [SP 800-38D], and [SP 800-232]).

710 711 712 713 714

•

Provide source and integrity authentication services in the form of MACs — The same key is used to generate the MAC and validate it. MACs normally employ either a symmetric-key algorithm or a cryptographic hash function as their cryptographic primitive (see CMAC, as specified in [SP 800-38B]; HMAC using a hash function, as specified in [SP 800-224]; and KMAC, as specified in [SP 800-185]).

15

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

715 716

•

Derive keying material from a pre-shared key using a key-derivation method (e.g., see [SP 800-108])

717 718

•

Derive a key from a shared secret during the use of an asymmetric key-establishment scheme (see [SP 800-56C])

719

•

Wrap keys using a key-wrapping algorithm (see [FIPS 197] and [SP 800-38F])

720

•

Generate random numbers (see Sec. 3.4)

721

3.3. Asymmetric-Key Algorithms

722 723 724 725 726 727

Asymmetric-key algorithms, commonly known as public-key algorithms, use two related keys (i.e., a key pair) to perform their functions: a public key and a private key. The public key may be known by anyone, while the private key should be under the sole control of the entity that “owns” the key pair. 7 Even though the public and private keys of a key pair are related, knowledge of the public key cannot be used to determine the private key. Asymmetric algorithms may be used to:

728 729

•

Provide source, identity, and integrity authentication services in the form of digital signatures or

730

•

Establish cryptographic keying material using key-establishment schemes.

731 732 733

Digital signatures are generated by the owner of a private key and can be verified by any party that has the corresponding public key. Approved digital signature algorithms are specified in [FIPS 186-5], [FIPS 204], [FIPS 205], and [SP 800-208].

734 735 736

Approved key-establishment schemes using asymmetric-key algorithms are specified in [SP 800-56A], [SP 800-56B], and [FIPS 203]. Additionally, [[SP 800-175B] discusses the use of asymmetric-key algorithms to generate digital signatures and establish keying material.

737

3.4. Random Bit Generation

738 739 740 741 742 743 744

Random bit generators (RBGs) 8 are required for the generation of keying material, such as keys and initialization vectors (IVs). RBGs generate sequences of random bits (e.g., 010011); technically, RNGs translate those bits into numbers (e.g., 010011 is translated into the number 19). However, the term “random number generator” (RNG) is commonly used to refer to both concepts. The use of RBGs is discussed in [SP 800-175B], and approved RBGs are specified in the SP 800-90 series of documents (i.e., [SP 800-90A], [SP 800-90B], and [SP 800-90C].

7 Sometimes, a key pair is generated by a party that is trusted by the key owner and then provided to the key owner. 8 RBGs may also be called “random number generators” or RNGs.

16

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

745

4. General Key-Management Guidelines

746 747 748 749 750 751 752

This section classifies the different types of keys and other cryptographic information according to their uses; discusses cryptoperiods and suggests appropriate cryptoperiods for each key type; provides recommendations and requirements for other keying material; introduces assurance of domain-parameter validity, public-key validity, and private-key possession; discusses the implications of the compromise of keying material; and provides guidelines for the selection, implementation, and replacement of cryptographic algorithms and key sizes according to their security strengths.

753

4.1. Key Types and Other Information

754 755 756 757 758

There are several different types of cryptographic keys, each used for a different purpose. However, some algorithms can be used for several different purposes, so the keys are listed separately for each purpose below. In addition, there is other information that is specifically related to cryptographic algorithms and keys. The generation of these keys is discussed in [SP 800-133].

759

4.1.1. Cryptographic Keys

760 761 762

Several different types of keys are defined below. The keys are identified according to their classification as public, private, or symmetric (i.e., secret) keys, and their use is indicated. See Table 8 in Section 5.1.1 for the required protections for each key type.

763

•

Digital signatures [FIPS 186-5][FIPS 204][FIPS 205][SP 800-208]:

764 765 766 767 768

1. Private signature key: A private signature key is the private-key component of an asymmetric-key (public-key) pair that is used by a public-key algorithm to generate digital signatures. When properly handled, a private signature key can be used to provide source authentication, integrity authentication, and nonrepudiation of messages, documents, and stored data.

769 770 771 772

2. Public signature-verification key: A public signature-verification key is the publickey component of an asymmetric-key (public-key) pair that is used by a public-key algorithm to verify digital signatures that were signed with the corresponding private signature key.

773 774 775 776 777 778 779 780

•

Authentication keys: 3. Symmetric authentication key: A symmetric authentication key is used with a symmetric-key algorithm to provide identity authentication and integrity authentication of communication sessions, messages, documents, and stored data. For the authenticated-encryption modes of operation for symmetric-key algorithms, a single key is used for both authentication and encryption modes. See [SP 800-38B], [SP 800-38C], [SP 800-38D], [SP 800-185], [SP 800-224], and [SP 800232].

17

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

781 782 783 784 785 786

4. Private authentication key: A private authentication key is the private-key component of an asymmetric-key (public-key) pair that is used with a public-key algorithm to provide assurance of the identity of an entity (i.e., identity authentication) when establishing an authenticated communication session or authorization to perform some action.9 See [FIPS 186-5], [FIPS 204], [FIPS 205], and [SP 800-208].

787 788 789 790

5. Public authentication key: A public authentication key is the public-key component of an asymmetric-key (public-key) pair that is used with a public-key algorithm to verify the identity of an entity (i.e., identity authentication) when establishing an authenticated communication session or authorization to perform some action.10

791

•

792 793 794

6. Symmetric random number generation key: This key is used to generate random numbers or random bits. See the SP 800-90 series. •

795 796 797 798 799

Keys for random bit/number generation:

Key derivation: 7. Symmetric key-derivation key: A symmetric key-derivation key (sometimes called a master key) is used to derive other symmetric keys (e.g., data-encryption keys, key-wrapping keys) using symmetric cryptographic methods. See [SP 800-108] and [SP 800-135].

•

Key establishment (automated):

800 801 802 803 804 805

8. Symmetric key-wrapping key: A symmetric key-wrapping key (sometimes called a key-encrypting key) is used with a symmetric-key algorithm to encrypt (i.e., wrap) other keys. The key-wrapping key used to encrypt a key is also used to reverse the encryption operation (i.e., decrypt/unwrap the encrypted key). Depending on the algorithm with which the key is used, the key may also be used to provide integrity protection. See [SP 800-38F].

806 807 808 809 810

9. Public key-transport key: A public key-transport key is the public-key component of an asymmetric-key (public-key) pair that is used to encrypt keys using a publickey algorithm. Public key-transport keys are used to establish (i.e., securely distribute) symmetric keys (e.g., key-wrapping keys, data-encryption keys, MAC keys) and, optionally, other keying material (e.g., an IV). See [SP 800-56B].

811 812 813 814

10. Private key-transport key: A private key-transport key is the private-key component of an asymmetric-key (public-key) pair that is used to decrypt keys that have been encrypted with the corresponding public key-transport key using a public-key algorithm. See [SP 800-56B].

815 816

11. Symmetric key-agreement key: This symmetric key is used to establish symmetric keys (e.g., key-wrapping keys, data-encryption keys, MAC keys) and, optionally,

9 While integrity protection is also provided, it is not the primary intention of this key.

10 While integrity protection is also provided, it is not the primary intention of this key.

18

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

817 818

other keying material (e.g., IVs) using a symmetric key-agreement algorithm. There are currently no NIST-approved methods for symmetric key agreement.

819 820 821 822 823

12. Public static key-agreement key: A public static key-agreement key is the longterm public-key component of an asymmetric-key (public-key) pair that is used to establish symmetric keys (e.g., key-wrapping keys, data-encryption keys, MAC keys) and, optionally, other keying material (e.g., IVs). See [SP 800-56A] and [SP 800-56B].

824 825 826 827 828

13. Private static key-agreement key: A private static key-agreement key is the longterm private-key component of an asymmetric-key (public-key) pair that is used to establish symmetric keys (e.g., key-wrapping keys, data-encryption keys, MAC keys) and, optionally, other keying material (e.g., IVs). See [SP 800-56A] and [SP 800-56B].

829 830 831 832 833

14. Public ephemeral key-agreement key: A public ephemeral key-agreement key is the public-key component of an asymmetric key pair that is used in a single keyestablishment transaction to establish one or more symmetric keys (e.g., keywrapping keys, data-encryption keys, MAC keys) and, optionally, other keying material (e.g., IVs). See [SP 800-56A].

834 835 836 837 838

15. Private ephemeral key-agreement key: A private ephemeral key-agreement key is the private-key component of an asymmetric-key (public-key) pair that is used in a single key-establishment transaction to establish one or more symmetric keys (e.g., key-wrapping keys, data-encryption keys, MAC keys) and, optionally, other keying material (e.g., IVs). See [SP 800-56A].

839 840 841 842 843

16. Public static encapsulation key: A public static encapsulation key is the long-term public-key component of an asymmetric-key (public-key) pair that is used during the encapsulation process in multiple key-establishment transactions to encapsulate symmetric keys (e.g., key-wrapping keys, data-encryption keys, MAC keys). See [FIPS 203] and [SP 800-227].

844 845 846 847 848

17. Private static decapsulation key: A private static decapsulation key is the longterm private-key component of an asymmetric-key (public-key) pair that is used in multiple key-establishment transactions to decapsulate symmetric keys that were encapsulated using the corresponding public static encapsulation key. See [FIPS 203] and [SP 800-227].

849 850 851 852

18. Public ephemeral encapsulation key: A public ephemeral encapsulation key is the public-key component of an asymmetric-key (public-key) pair that is used in a single key-establishment transaction to encapsulate symmetric keys (e.g., a keywrapping key, data-encryption key, MAC keys). See [FIPS 203] and [SP 800-227].

853 854 855

19. Private ephemeral decapsulation key: A private ephemeral decapsulation key is the private-key component of an asymmetric-key (public key) pair that is used in a single key-establishment transaction to decapsulate symmetric keys that were

19

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

856 857 858

Recommendation for Key Management Part 1 — General

encapsulated using the corresponding public ephemeral encapsulation key. See [FIPS 203] and [SP 800-227]. •

Key storage (for operational, backup, and archive storage):

859 860 861 862 863 864

20. Symmetric key-wrapping key: A symmetric key-wrapping key (sometimes called a key-encrypting key) is used with a symmetric-key algorithm to wrap (i.e., encrypt and protect the integrity of) other keys for storage (e.g., the key-wrapping key used to wrap a key is also used to unwrap the wrapped key). Depending on the algorithm with which the key is used, the key may also be used to provide integrity protection. See [SP 800-38F].

865 866 867 868 869 870 871

21. Public key-wrapping key: A public key-wrapping key is the public-key component of an asymmetric-key (public-key) pair that is used to wrap (i.e., encrypt and protect the integrity of) keys using a public-key algorithm. This key is used to store symmetric keys (e.g., key-wrapping keys, data-encryption keys, MAC keys) and, optionally, other keying material (e.g., IVs). The RSA algorithm may be used for this purpose, but there is currently no NIST publication that specifically discusses this use.

872 873 874 875 876

22. Private key-unwrapping key: A private key-unwrapping key is the private-key component of an asymmetric-key (public-key) pair that is used to unwrap (i.e., decrypt and verify the integrity of) a key that has been wrapped with the corresponding public key-wrapping key using a public-key algorithm. There is currently no NIST publication that specifically discusses this use.

877 878 879 880

23. Public encapsulation key: A public encapsulation key is typically the long-term public-key component of an asymmetric-key (public-key) pair that is used during the encapsulation process to encapsulate symmetric keys for storage (e.g., keywrapping keys, data-encryption keys, MAC keys). See [FIPS 203].

881 882 883 884

24. Private decapsulation key: A private decapsulation key is the private-key component of an asymmetric-key (public-key) pair that is used to decapsulate symmetric keys that were encapsulated using the corresponding public encapsulation key. See [FIPS 203].

885

•

Authorization:

886 887 888 889 890

25. Symmetric authorization key: A symmetric authorization key is used to provide privileges to an entity using a symmetric cryptographic method. The authorization key is known by both the entity responsible for monitoring and granting access privileges for authorized entities and the entity seeking access to resources. There is currently no NIST publication that specifically discusses this use.

891 892 893 894 895

26. Private authorization key: A private authorization key is the private-key component of an asymmetric-key (public-key) pair that is used to prove the owner’s right to privileges (e.g., using a digital signature). See [FIPS 186-5], [FIPS 204], [FIPS 205], and [SP 800-208]. There is currently no NIST publication that specifically discusses this use. 20

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

896 897 898 899 900

Recommendation for Key Management Part 1 — General

27. Public authorization key: A public authorization key is the public-key component of an asymmetric-key (public-key) pair that is used to verify privileges for an entity that knows the associated private authorization key. See [FIPS 186-5], [FIPS 204], [FIPS 205], and [SP 800-208]. There is currently no NIST publication that specifically discusses this use.

901

4.1.2. Other Related Information

902 903 904

Other information used in conjunction with cryptographic algorithms and keys also needs to be protected. See Table 6 in Section 5.1.2 for the required protections for each type of information. Information to be protected may include:

905 906 907 908 909

•

Algorithm Parameters: Algorithm parameters are used in conjunction with some algorithms to generate keys, create digital signatures, or establish keying material. For elliptic curve algorithm, the algorithm parameters are called domain parameters. See [FIPS 186-5], [SP 800-56A], [FIPS 203], [FIPS 204], [FIPS 205], [SP 800-208], and [SP 800-232].

910 911

•

Initialization Vectors: IVs are used by several modes of operation for encryption, decryption, and the computation of MACs using block-cipher algorithms. See Sec. 4.2.

912 913

•

Shared Secrets: Shared secrets 11 are generated during a key-agreement process and are not suitable for use as keys. See [SP 800-56A] and [SP 800-56B].

914

•

Seeds:

915 916 917

o Seeds are used for the generation of deterministic random bits (e.g., used to generate keying material that must remain secret or private). See the SP 80090 series.

918 919 920

o Seeds are used during the generation of keying material according to an algorithm specification. See [FIPS 203], [FIPS 204], [FIPS 205], and [SP 800208].

921 922

•

Other public information: Public information (e.g., a nonce) is often used in keyestablishment and key-confirmation processes.

923 924 925

•

Other secret information: Secret information may be included in the seeding of an RBG or the establishment of keying material. See [SP 800-56A], [SP 800-56B], the SP 800-90 series, and [SP 800-108].

926 927

•

Intermediate results: The intermediate results in cryptographic operations often needs protection.

928 929 930

•

Key-control information/metadata: Information related to the keying material (e.g., a key identifier, the purpose intended for the key, or a counter) must be protected to ensure that the associated keying material can be correctly used. The key-control

11 These not the shared secret keys output by a key-encapsulation algorithm (e.g., see [FIPS 203]).

21

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

931 932

Recommendation for Key Management Part 1 — General

information is included in the metadata associated with the keying material (see Sec. 5.2.3).

933 934

•

Random bits (or numbers): The random bits created by an RBG. See the SP 800-90 series.

935 936 937 938

•

Passwords: A password is used to acquire access to privileges and can be used as a credential in a source-authentication or identity-authentication mechanism. A password can also be used to derive cryptographic keys that are used to protect and access data in storage. See [SP 800-132].

939

•

Audit information: Audit information contains a record of key-management events.

940

4.2. Key Usage

941 942 943

In general, a single key should be used for only one purpose (e.g., encryption, integrity authentication, key wrapping, random bit generation, or digital signatures). There are several reasons for this:

944 945

•

Using the same key for two different cryptographic processes may weaken the security provided by one or both processes.

946 947

•

Limiting the use of a key limits the damage that could be done if the key is compromised.

948 949 950 951 952 953 954 955 956 957

•

Some uses of keys interfere with each other. For example, consider an RSA key pair used for both key transport and digital signatures. In this case, the private key is used as both a private key-transport key to decrypt the encrypted keys and as a private signature key to generate digital signatures. It may be necessary to retain the private key used for key transport beyond the cryptoperiod of the corresponding public key to decrypt the encrypted keys needed to access encrypted data. The private key used for signature generation needs to be destroyed at the expiration of its cryptoperiod to prevent its compromise (see Sec. 4.3.6). In this example, the longevity requirements for the private key-transport key and the private digital signature key contradict each other.

958 959 960 961 962 963

This principle does not preclude using a single key if the same process can provide multiple services. This is the case, for example, when a digital signature provides integrity authentication and source authentication using a single digital signature or when a single symmetric key can be used to encrypt and authenticate data in a single cryptographic operation (e.g., using an authenticated-encryption operation as opposed to separate encryption and authentication operations) (see Sec. 2.7).

964 965 966 967

This recommendation permits the use of a private key-transport or key-agreement key to generate a digital signature when requesting the (initial) certificate for a static keyestablishment key that was generated as specified in [FIPS 186-5] (see [SP 800-56A], [SP 80056B], and Sec. 7.1.5.1.1.2).

22

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

968

4.3. Cryptoperiods

969 970

A cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect. A suitably defined cryptoperiod:

971 972

•

Limits the amount of information that is available for cryptanalysis to reveal the key (e.g., the number of plaintext and ciphertext pairs encrypted with the key);

973

•

Limits the amount of exposure if a single key is compromised;

974

•

Limits the use of a particular algorithm (e.g., to its estimated effective lifetime);

975 976

•

Limits the time available for attempts to penetrate physical, procedural, and logical access mechanisms that protect a key from unauthorized disclosure;

977 978

•

Limits the period within which information may be compromised by the inadvertent disclosure of a cryptographic key to unauthorized entities; and

979

•

Limits the time available for computationally intensive cryptanalysis.

980 981 982 983 984 985

Cryptoperiods are sometimes defined by an arbitrary time period or maximum amount of data protected by the key. However, trade-offs associated with the determination of cryptoperiods involve the risk and consequences of exposure, which should be carefully considered when selecting the cryptoperiod (see Sec. 4.3.4). If a key is compromised, its cryptoperiod shall no longer be considered valid. See Sec. 4.5 for discussions on handling compromised keys.

986

4.3.1. Factors Affecting Cryptoperiods

987

Some factors that affect the length of a cryptoperiod include:

988 989

•

The strength of the cryptographic mechanisms (e.g., the algorithm, key length, block size, or mode of operation)

990 991

•

The embodiment of the mechanisms (e.g., a [FIPS 140-3] Level 4 implementation or a software implementation on a personal computer)

992 993

•

The operating environment (e.g., a secure limited-access facility, open office environment, or publicly accessible terminal)

994

•

Personnel turnover (e.g., of system administrators and CA system personnel)

995

•

The volume of data flow or the number of transactions

996

•

The security life of the data

997 998

•

Limitations required for algorithm use (e.g., the maximum number of invocations to avoid nonce reuse)

999 1000

•

The security function (e.g., data encryption, digital signature, key derivation, or key protection)

23

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1001 1002

•

The re-keying method (e.g., keyboard entry, re-keying using a key-loading device where humans have no direct access to keys, or remote re-keying within a PKI)

1003

•

The re-keying or key-derivation process used

1004

•

The number of nodes in a network that share a common key

1005

•

The number of copies of a key and the distribution of those copies

1006 1007

•

The threat to the information from adversaries (e.g., their perceived technical capabilities and financial resources to mount an attack)

1008 1009

•

The threat to the information from new and disruptive technologies (e.g., quantum computers)

1010 1011 1012 1013 1014 1015 1016

In general, short cryptoperiods enhance security. For example, some cryptographic algorithms might be less vulnerable to cryptanalysis if the adversary has only a limited amount of information encrypted under a single key. However, when manual key-distribution methods are subject to human error and frailty, more frequent key changes might actually increase the risk of key exposure. In these cases, especially when very strong cryptography is employed in hardware, it may be more prudent to have fewer, well-controlled manual key distributions rather than more frequent, poorly controlled manual key distributions.

1017 1018 1019 1020 1021

When strong cryptography is employed, physical, procedural, and logical considerations for access protection often have more impact on cryptoperiod selection than algorithm and keysize factors. When approved algorithms, modes of operation, and key sizes are used, adversaries may be able to access keys by penetrating or subverting a system with less time and fewer resources than would be required to mount and execute a cryptographic attack.

1022

4.3.2. Consequence Factors Affecting Cryptoperiods

1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034

The consequences of exposure are measured by the sensitivity of the information, the criticality of the processes protected by the cryptography, and the cost of recovering from the compromise of information or processes. Sensitivity refers to the lifespan of the information being protected (e.g., 10 minutes, 10 days or 10 years) and the potential consequences of a loss of protection for that information (e.g., the disclosure of the information to unauthorized entities). In general, as the sensitivity of the information or the criticality of the processes protected by cryptography increase, the length of the associated cryptoperiods should decrease to limit the damage that might result from each compromise. This is subject to the caveat regarding the security and integrity of the re-keying or keyderivation process (see Sec. 7.2.3 and 7.2.4). However, short cryptoperiods may be counterproductive, particularly if denial of service is a paramount concern and there is a significant potential for error in the re-keying or key-derivation process.

24

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1035

4.3.3. Other Factors Affecting Cryptoperiods

1036

4.3.3.1. Communications Versus Storage

1037 1038 1039 1040

Keys that are used to protect the confidentiality of communication exchanges may often have shorter cryptoperiods than keys used for the protection of stored data. Cryptoperiods are generally made longer for stored data because the overhead of generating new keys and reencrypting all data that was encrypted using the old keys may be burdensome.

1041

4.3.3.2. Cost of Key Revocation and Replacement

1042 1043 1044 1045 1046 1047 1048 1049

In some cases, the costs associated with changing keys are painfully high. Examples include the decryption and subsequent re-encryption of very large or distributed databases and the revocation and replacement of a very large number of keys (e.g., where there are very large numbers of geographically and organizationally distributed key holders). In such cases, the expense of the security measures necessary to support longer cryptoperiods may be justified. In other cases, the cryptoperiod may be shorter than would otherwise be necessary (e.g., to limit the period of time during which a key-management system maintains status information).

1050

4.3.4. Asymmetric Key Usage Periods and Cryptoperiods

1051 1052 1053 1054 1055

For asymmetric-key key pairs, each key of the pair has its own cryptoperiod. One key of the key pair is used to apply cryptographic protection (e.g., create a digital signature). The other key of the key pair is used to process the protected information (e.g., verify a digital signature). The two cryptoperiods typically begin at the same time, but one of the cryptoperiods may need to be longer than the other. For example:

1056 1057 1058

•

In the case of digital signature key pairs, the private signature key is used to sign data (i.e., apply cryptographic protection), and the public signature-verification key is used to verify digital signatures (i.e., process information that has already been protected).

1059 1060 1061 1062 1063 1064

For a private signature key that is used to generate digital signatures as a proof-oforigin (i.e., for source authentication), the cryptoperiod of the private key may be shorter than the cryptoperiod of the public signature-verification key. In this case, the private key is intended for use for a fixed period of time after which the key owner shall destroy 12 the private key. The public key may be available for a longer period to verify signatures.

1065 1066

The cryptoperiod of a private source-authentication key that is used to sign challenge information is basically the same as the cryptoperiod of the corresponding public key

A simple deletion of the keying material might not completely obliterate the information. For example, erasing the information might require overwriting that information multiple times with other non-related information, such as random bits or all zero or one bits. Keys stored in memory for a long time can become “burned in.” Splitting the key into shares that are frequently updated can mitigate this problem [DiCrescenzo].

12

25

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

1067 1068

Recommendation for Key Management Part 1 — General

(i.e., the public source-authentication key). That is, when the private key will no longer be used to sign challenges, the public key is no longer needed.

1069 1070 1071 1072 1073

•

For key-transport keys, the public key-transport key is used to apply protection (i.e., encrypt a key), and the private key-transport key is used to decrypt the encrypted key. The cryptoperiod during which the public key-transport key may be used for encryption may be shorter than the cryptoperiod of the corresponding private keytransport key used to decrypt the encrypted key.

1074 1075 1076 1077 1078 1079 1080

•

For a key-encapsulation mechanism (KEM), the public encapsulation key of the intended receiver is used by the sending entity to encapsulate a key generated by the sending entity before sending the resulting ciphertext to the intended receiver. The receiver’s corresponding private decapsulation key is subsequently used to decapsulate the received ciphertext. The cryptoperiod of the private decapsulation key may need to be longer than the cryptoperiod of the corresponding encapsulation key.

1081 1082 1083 1084 1085 1086 1087

•

For key-agreement algorithms, the cryptoperiods of the two keys of the key pair are usually the same, although there are exceptions. For example, for the KAS1 scheme in [SP 800-56B], the recipient’s public key is used to encrypt keying material sent to the recipient by the scheme’s originator. The recipient subsequently uses the corresponding private key to decrypt the received ciphertext keying material. The cryptoperiod of the recipient’s private key may need to be longer than the cryptoperiod of the corresponding public key.

1088 1089 1090 1091 1092 1093

When public keys are distributed in public-key certificates, a certificate often includes a validity period for the public key indicated by the notBefore and notAfter dates in the certificate. Certificates may be renewed (e.g., a new certificate containing the same public key may be issued with a new validity period). The range of time covered by the original certificate and all renewed certificates for the same public key shall not extend beyond the cryptoperiod of the public key. See Sec. 4.3.6 for guidelines regarding specific key types.

1094

4.3.5. Symmetric Key Usage Periods and Cryptoperiods

1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105

For symmetric keys, a single key is used for both applying the protection (e.g., encrypting or computing a MAC on data) and processing the protected information (e.g., decrypting the encrypted data or verifying a MAC). The period during which cryptographic protection may be applied to data is called the originator-usage period, and the period during which the protected information is processed is called the recipient-usage period. A symmetric key shall not be used to provide protection after the end of the originator-usage period. The recipientusage period may extend beyond the originator-usage period (see Fig. 1). This permits information that has been protected by the originator to be processed by the recipient for an extended period after the protection has been applied. However, in many cases, the originator and recipient-usage periods are the same. The total “cryptoperiod” of a symmetric key is the period from the beginning of the originator-usage period to the end of the recipient-

26

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

1106 1107

Recommendation for Key Management Part 1 — General

usage period (see Fig. 1), although the originator-usage period has historically been used as the cryptoperiod for the key.

1108 1109

Fig. 1. Symmetric-key cryptoperiod

1110 1111 1112

In some cases, predetermined cryptoperiods may not be adequate for the security life of the protected data. If the required security life exceeds the cryptoperiod, then the protection may need to be reapplied using a new key.

1113

Examples of the usage periods for symmetric keys include:

1114 1115 1116 1117

•

When a symmetric key is only used for securing communications, the period from the originator’s application of protection to the recipient’s processing may be negligible. In this case, the key is authorized for either purpose during the entire cryptoperiod (i.e., the originator-usage period and the recipient-usage period are the same).

1118 1119 1120 1121 1122 1123 1124 1125

•

When a symmetric key is used to protect stored information, the originator-usage period (i.e., when the originator applies cryptographic protection to stored information) may end much earlier than the recipient-usage period (i.e., when the stored information is processed). In this case, the cryptoperiod begins at the initial time authorized for the application of protection with the key and ends with the latest time authorized for processing using that key. In general, the recipient-usage period for stored information will continue beyond the originator-usage period so that the stored information may be authenticated or decrypted at a later time.

1126 1127 1128 1129 1130

•

When a symmetric key is used to protect stored information, the recipient-usage period may start after the beginning of the originator-usage period, as shown in Fig. 1. For example, information may be encrypted before being stored on some storage media. At a later time, the key may be distributed in order to decrypt and recover the information.

1131

4.3.6. Cryptoperiod Recommendations for Specific Key Types

1132 1133 1134

The key type, usage environment, and data characteristics described above may affect the cryptoperiod required for a given key. This document suggests cryptoperiods for various key types as lengths of time. Other measures for the cryptoperiod (e.g., the number of uses of

27

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1135 1136 1137 1138 1139 1140

each key for a given cryptographic algorithm to protect information) may require appropriate adjustments. The suggested cryptoperiods are based more on the effectiveness of access mechanisms for keys than on the strength of the cryptographic mechanisms that use the keys. For example, the assignment of a one-year cryptoperiod versus a two-year period is primarily driven by the concern that unauthorized physical or logical access to the key is more likely to occur within two years than within one year.

1141 1142 1143 1144 1145 1146 1147 1148

The suggested cryptoperiods are only rough order-of-magnitude guidelines. Longer or shorter cryptoperiods may be warranted, depending on the consequences of compromised confidentiality or integrity compromises, the supported application, and the environment in which the keys will be used. When assigning a longer cryptoperiod, serious consideration should be given to the risks associated with doing so (see Sec. 4.3.1). Most of the suggested cryptoperiods are based on supporting maximum operational efficiency and assumptions regarding the minimum security criteria for the usage environment (see [FIPS 140-3] and [SP 800-37]).

1149 1150 1151 1152

The factors described in Sec. 4.3.1 through 4.3.3 should be used to determine actual cryptoperiods for specific usage environments. Given the use of an approved algorithm and an appropriate key size for the protected information, suggested cryptoperiods for each key type are as follows:

1153 1154

•

Digital signatures 1. Private signature key

1155 1156 1157 1158 1159

Type Considerations: In general, the cryptoperiod of a private signature key may be shorter than the cryptoperiod of the corresponding public signatureverification key. When the corresponding public key has been certified by a CA, the cryptoperiod for a private signature key ends no later than the notAfter date on the last certificate issued for the public key. 13

1160 1161 1162 1163 1164

Cryptoperiod: Given an expectation that the security of the key-storage and use environment will increase as the sensitivity and/or criticality of the processes for which the key provides integrity protection increases, a maximum cryptoperiod of about one to three years is suggested. A private signature key shall be destroyed at the end of its cryptoperiod.

1165 1166 1167 1168 1169 1170 1171

2. Public signature-verification key Type Considerations: In general, the cryptoperiod of a public signature-verification key may be longer than the cryptoperiod of the corresponding private signature key. The cryptoperiod is, in effect, the period during which any signature computed using the corresponding private signature key needs to be verified. A longer cryptoperiod for a public signature-verification key (than that of the private signature key) poses a relatively minimal security concern.

13 Multiple consecutive certificates may be issued for the same public key, presumably with different notBefore and notAfter validity dates.

28

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1172 1173 1174 1175 1176 1177 1178 1179 1180

Cryptoperiod: The cryptoperiod may be a number of years longer than that of the corresponding private signature key. However, due to the long exposure of protection mechanisms to hostile attack, the reliability of the signature verification is reduced with the passage of time. That is, for any given algorithm and key size, vulnerability to cryptanalysis is expected to increase with time. Although choosing the strongest algorithm available and a large key size can minimize this vulnerability to cryptanalysis, the consequences of exposure to attacks on physical, procedural, and logical access-control mechanisms for the private key are not affected by algorithm selection.

1181 1182 1183 1184 1185 1186 1187

Some systems use a cryptographic timestamping function to place an unforgeable timestamp on each signed message. Even when the cryptoperiod of a private signature key has expired, the corresponding public signature-verification key may be used to verify signatures on messages whose timestamps are within the cryptoperiod of the private signature key. In this case, one is relying on the cryptographic timestamp function to provide assurance that the message was signed within the cryptoperiod of the private signature key.

1188 1189

•

Authentication keys 3. Symmetric authentication key

1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205

Type Considerations: The cryptoperiod of a symmetric authentication key14 depends on the sensitivity of the type of information being protected and the protection afforded by the key and associated algorithm. For very sensitive information, an authentication key may need to be unique to the protected information. For less sensitive information, a suitable cryptoperiod may extend beyond a single use of the key. The originator-usage period of a symmetric authentication key applies to the use of that key in applying the original cryptographic protection for the information (e.g., computing the MAC). New MACs shall not be computed on information using that key after the end of the originator-usage period. However, the key may need to be available to verify the MAC on the protected data beyond the originator-usage period (i.e., the recipientusage period may extend beyond the originator-usage period). The recipientusage period is the period during which a MAC that was generated during the originator-usage period needs to be verified. However, if a MAC key is compromised, it may be possible for an adversary to modify the data and then recalculate the MAC.

1206 1207 1208 1209 1210

Cryptoperiod: Given an expectation that the security of the key-storage and use environment will increase as the sensitivity and/or criticality of the processes for which the key provides integrity protection increases, an originator-usage period of no more than two years is recommended. The recipient-usage period should not extend more than three years beyond the end of the originator-usage period.

14 This is used to enable data integrity and source authentication.

29

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

1211

Recommendation for Key Management Part 1 — General

4. Private authentication key

1212 1213 1214 1215

Type Considerations: A private authentication key may be used for multiple data integrity processes and identity authentication events. In most cases, the cryptoperiod of a private authentication key is the same as the cryptoperiod of the corresponding public key.

1216 1217 1218

Cryptoperiod: An appropriate cryptoperiod for a private authentication key would be no more than one or two years, depending on its usage environment and the sensitivity/criticality of the authenticated information.

1219

5. Public authentication key

1220 1221 1222 1223

Type Considerations: The cryptoperiod is, in effect, the period during which the identity of the originator of the information protected by the corresponding private authentication key needs to be verified (i.e., the identity needs to be authenticated). 15

1224 1225

Cryptoperiod: In most cases, the cryptoperiod of a public authentication key is the same as the cryptoperiod of the corresponding private authentication key.

1226

•

1227

Keys for random bit/number generation 6. Symmetric random number generation key

1228 1229 1230 1231

Type Considerations: A symmetric RBG key is used in a deterministic random bit generation function. The approved RBGs in the SP 800-90 series control key changes (e.g., during reseeding). The cryptoperiod consists of only an originatorusage period.

1232 1233 1234

Cryptoperiod: Assuming the use of an approved RBG, the maximum cryptoperiod of a symmetric RBG key is determined by the design of the RBG (see the SP 80090 series).

1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247

•

Key derivation 7. Symmetric key-derivation key/master key Type Considerations: A symmetric key-derivation key (also called a master key in some environments) may be used multiple times to derive other keys using a (oneway) key-derivation function or method (see Sec. 7.2.4). Therefore, the cryptoperiod consists of only an originator-usage period for this key type. A suitable cryptoperiod depends on the nature and use of the derived keys and on considerations provided in Sec. 4.3. The cryptoperiod of a key derived from a keyderivation key could be relatively short (e.g., used only for a single use, communication session, or transaction). Alternatively, the key-derivation key could be used over a longer period to derive (or re-derive) multiple keys for the same or different purposes. The cryptoperiod of the derived keys depends on their use (e.g., for symmetric data-encryption or integrity authentication).

15 While integrity protection is also provided, it is not the primary intention of this key.

30

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

1248 1249 1250 1251 1252 1253

Recommendation for Key Management Part 1 — General

Cryptoperiod: An appropriate cryptoperiod for a symmetric key-derivation key might be one year, depending on its usage environment, the sensitivity/criticality of the information protected by the derived keys, and the number of keys derived from the key-derivation key. •

Key establishment (automated) 8. Symmetric key-wrapping/unwrapping key

1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266

Type Considerations: A symmetric key-wrapping key that is used to wrap (i.e., encrypt and integrity protect) very large numbers of keys over a short period of time should have a relatively short originator-usage period. If a small number of keys are wrapped, the originator-usage period of the key-wrapping key could be longer. The originator-usage period of a symmetric key-wrapping key applies to the use of that key in providing key-wrapping protection for the keys. A wrapping operation shall not be performed using a key-wrapping key whose originatorusage period has expired. However, the key-wrapping key may need to be available to unwrap the protected keys (i.e., to decrypt and verify the integrity of the wrapped keys) beyond the originator-usage period (i.e., the recipient-usage period may need to extend beyond the originator-usage period). The recipientusage period is the period during which keys that were wrapped during the keywrapping key’s originator-usage period may need to be unwrapped.

1267 1268 1269 1270 1271 1272 1273 1274 1275 1276

Some symmetric key-wrapping keys are used for only a single message or communication session. In the case of these very short-term key-wrapping keys, an appropriate cryptoperiod is a single communication session (i.e., includes both the originator and recipient-usage periods). If the wrapped keys are not retained in their wrapped form, the originator-usage period and recipient-usage period of a key-wrapping key is the same. In other cases, a key-wrapping key may be retained (i.e., stored) so that the files or messages encrypted by the wrapped keys may be recovered later. In such cases, the recipient-usage period may be significantly longer than the originator-usage period of the key-wrapping key, and cryptoperiods lasting for years may be employed.

1277 1278 1279 1280 1281 1282 1283 1284 1285

Cryptoperiod: The recommended originator-usage period for a symmetric keywrapping key that is used to wrap very large numbers of keys over a short period of time is on the order of a day or week. If a relatively small number of keys are to be wrapped under a key-wrapping key, the originator-usage period of the keywrapping key could be up to two years. In the case of a key-wrapping key that is used for only a single message or communication session, the cryptoperiod would be limited to a single communication session. It is recommended that a recipientusage period extend no more than three years beyond the end of the originatorusage period.

1286 1287 1288

9. Public key-transport key Type Considerations: The cryptoperiod for a public key-transport key is that period during which the public key may be used to apply the encryption operation to the 31

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1289 1290 1291 1292

keys that will be protected during transport (i.e., via automated, online distribution). When the public key has been certified by a CA, the cryptoperiod for the public key ends when the notAfter date is reached on the last certificate issued for the public key.

1293 1294 1295 1296

A public key-transport key can be publicly known. Due to the potential need to decrypt keys after they have been encrypted for transport, the cryptoperiod of a public key-transport key may be shorter than that of the corresponding private key-transport key.

1297 1298 1299

Cryptoperiod: Based on cryptoperiod assumptions for the corresponding private key, a recommendation for the cryptoperiod of the public key-transport key is no more than one or two years.

1300

10. Private key-transport key

1301 1302 1303 1304 1305 1306

Type Considerations: A private key-transport key may be used multiple times to decrypt keys. Due to the potential need to decrypt keys after they have been encrypted for transport, the cryptoperiod of the private key-transport key may be longer than the cryptoperiod of the corresponding public key. The cryptoperiod of the private key is the length of time during which any keys encrypted by the corresponding public key-transport key need to be decrypted.

1307 1308 1309 1310 1311 1312 1313 1314

Cryptoperiod: Given 1) the volume of information that may be protected by keys encrypted under the corresponding public key-transport key and 2) an expectation that the security of the key-storage and use environment will increase as the sensitivity and/or criticality of the processes for which the key provides protection increases, a cryptoperiod of no more than two years is recommended for a private key-transport key. In certain applications (e.g., email) where received messages are stored and decrypted at a later time, the cryptoperiod of a private key-transport key may exceed the cryptoperiod of the public key-transport key.

1315

11. Symmetric key-agreement key

1316 1317 1318 1319 1320 1321

Type Considerations: A symmetric key-agreement key may be used in multiple key-agreement transactions. The cryptoperiod of a symmetric key-agreement key depends on 1) environmental security factors; 2) the types, formats, and volume of keys that are established; and 3) the details of the key-agreement algorithm and protocol employed. A symmetric key-agreement key may be used to establish symmetric keys (e.g., symmetric data-encryption keys and IVs).

1322 1323 1324 1325 1326 1327

Cryptoperiod: Given an assumption that 1) the cryptographic device meets [FIPS 140-3] requirements and 2) the risk level has been established in conformance with [FIPS 199], an appropriate cryptoperiod for a symmetric key-agreement key would be no more than one or two years. In certain applications (e.g., email) where received messages are stored for decryption at a later time, the recipientusage period of the key may exceed the originator-usage period.

1328

12. Public static key-agreement key

32

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1329 1330 1331 1332 1333 1334

Type Considerations: A public static key-agreement key may be used in multiple key-agreement transactions. The cryptoperiod for a public static key-agreement key is usually the same as the cryptoperiod of the corresponding private static keyagreement key. When the public key has been certified by a CA, the cryptoperiod for the public key ends when the notAfter date is reached on the last certificate issued for the public key.

1335 1336

Cryptoperiod: The cryptoperiod of a public static key-agreement key may be one or two years.

1337

13. Private static key-agreement key

1338 1339

Type Considerations: A private static key-agreement key may be used for multiple key-agreement transactions.

1340 1341 1342 1343 1344

Cryptoperiod: The cryptoperiod of this key depends on 1) environmental security factors; 2) the types, formats, and volume of keys that are established; and 3) the details of the key-agreement algorithm and protocol employed. A private static key-agreement key may be used to establish symmetric keys (e.g., key-wrapping keys) or other secret keying material.

1345 1346 1347 1348 1349 1350 1351 1352

Given an assumption that 1) the cryptographic device meets [FIPS 140-3] requirements and 2) the risk level has been established in conformance with [FIPS 199], an appropriate cryptoperiod for the key would be no more than one or two years. While the cryptoperiods of the private and public static key-agreement keys are usually the same, in certain applications (e.g., email) where received messages are stored and decrypted at a later time, the cryptoperiod of a private static keyagreement key may exceed the cryptoperiod of the corresponding public static key-agreement key.

1353

14. Public ephemeral key-agreement key

1354 1355 1356

Type Considerations: A public ephemeral key-agreement key is the public-key component of an asymmetric key pair that is used in a single key-agreement transaction.

1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368

Cryptoperiod: The cryptoperiod of a public ephemeral key-agreement key ends immediately after it is used to generate a shared secret that is used to derive keying material. In some cases, the cryptoperiod of a public ephemeral keyagreement key may be different for the participants in the key-agreement transaction. For example, consider an encrypted email application in which the email sender generates an ephemeral key-agreement key pair and then uses the key pair to generate a key-encrypting key that is used to encrypt a content encryption key. For the sender, the cryptoperiod of the public key ends when the shared secret is generated, and the key-encrypting key is derived. However, for the email receiver, the cryptoperiod of the sender’s ephemeral public key does not end until the email is deleted, since the shared secret must be generated, and the key-encrypting key must be determined each time the email is read.

33

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

1369

Recommendation for Key Management Part 1 — General

15. Private ephemeral key-agreement key

1370 1371 1372 1373

Type Considerations: A private ephemeral key-agreement key is the private component of an asymmetric key pair that is used in a single transaction to establish one or more symmetric keys (e.g., key-wrapping keys) or other secret keying material.

1374 1375 1376

Cryptoperiod: The cryptoperiod of a private ephemeral key-agreement key is used to generate a shared secret after which the private ephemeral key shall be destroyed.

1377

16. Public static encapsulation key

1378 1379 1380 1381 1382 1383

Type Considerations: The cryptoperiod for a public static encapsulation key is the period during which the public key is used to generate and encapsulate symmetric keys to be provided to the owner of the static encapsulation/decapsulation key pair in multiple key-establishment transactions. When the public key has been certified by a CA, the cryptoperiod for the public key ends when the notAfter date is reached on the last certificate issued for the public static encapsulation key.

1384 1385 1386 1387 1388 1389 1390

Cryptoperiod: The cryptoperiod of the public static encapsulation key depends on 1) environmental security factors; 2) the types, formats, and volume of keys that are established; and 3) the details of the algorithm and protocol employed. Given an assumption that the 1) the cryptographic device meets [FIPS 140-3] requirements, and 2) the risk level has been established in conformance with [FIPS 199], an appropriate cryptoperiod for the public static encapsulation key would be no more than one or two years.

1391

17. Private static decapsulation key

1392 1393 1394

Type Considerations: A private static decapsulation key is used by the owner of the static key pair to decapsulate symmetric keys that were generated and encapsulated using the corresponding public static encapsulation key.

1395 1396 1397 1398 1399 1400 1401 1402

Cryptoperiod: Due to the potential need to decapsulate a key after the execution of the key-establishment transaction in which it was received, the cryptoperiod of the private static decapsulation key may need to be longer than the cryptoperiod of the corresponding public static encapsulation key. The cryptoperiod of the private static decapsulation key is the length of time during which any key that was generated and encapsulated using the corresponding public key needs to be decapsulated. A cryptoperiod of no more than two years is recommended for a private static decapsulation key.

1403 1404 1405 1406 1407

18. Public ephemeral encapsulation key Type Considerations: An ephemeral encapsulation/decapsulation key pair is generated by the entity that will perform decapsulation, and the public encapsulation key is provided to the entity that will perform encapsulation. The encapsulating entity uses the encapsulation key in a single key-establishment

34

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1408 1409

transaction to encapsulate a symmetric key to be provided to the decapsulating entity (i.e., the owner of the ephemeral key pair) as ciphertext.

1410 1411 1412

Cryptoperiod: The cryptoperiod of a public ephemeral encapsulation key ends immediately after it is used to encapsulate a key to be sent to the owner of the ephemeral key pair.

1413

19. Private ephemeral decapsulation key

1414 1415 1416 1417

Type Considerations: A private ephemeral decapsulation key is used in a single key-establishment transaction by the owner of the ephemeral encapsulation/decapsulation key pair to decapsulate a (ciphertext) symmetric key received during that transaction.

1418 1419 1420 1421 1422 1423 1424 1425 1426

Cryptoperiod: Due to the potential need to decapsulate a key after the keyestablishment transaction that used the corresponding public ephemeral encapsulation key, the cryptoperiod of the decapsulation key may be longer than the cryptoperiod of the corresponding public ephemeral encapsulation key (i.e., the duration of the key-establishment transaction). The cryptoperiod of the private ephemeral decapsulation key is the length of time during which the key encapsulated by the corresponding public ephemeral encapsulation key needs to be decapsulated. A private ephemeral decapsulation key shall be destroyed as soon as possible after use.

1427 1428

•

Data encryption/decryption key 20. Symmetric data-encryption/decryption key (for data in transit)

1429 1430 1431 1432 1433 1434 1435 1436

Type Considerations: A symmetric data-encryption key is used to protect data and messages in transit during communication sessions. Based primarily on the consequences of a compromise, a data-encryption key that is used to encrypt large volumes of data over a short period of time (e.g., for link encryption) should have a relatively short originator-usage period. An encryption key used to encrypt less data over time could have a longer originator-usage period. The originatorusage period of a symmetric data-encryption key applies to the use of that key for encrypting information (see Sec. 4.3.5).

1437 1438 1439 1440 1441

During the originator-usage period, encryption of the data may be performed using the data-encryption key. The key shall not be used to perform an encryption operation on data beyond this period. However, the key may need to be available to decrypt the protected data beyond the originator-usage period (i.e., the recipient-usage period may need to extend beyond the originator-usage period).

1442 1443 1444 1445 1446 1447

Cryptoperiod: The originator-usage period recommended for the encryption of large volumes of data over a short period of time (e.g., for link encryption) is on the order of a day or week. An encryption key used to encrypt smaller volumes of data might have an originator-usage period of up to two years. A recipient-usage period of no more than three years beyond the end of the originator-usage period is suggested.

35

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

1448

Recommendation for Key Management Part 1 — General

21. Symmetric data encryption/decryption key (for data at rest)

1449 1450 1451 1452 1453

Type Considerations: A symmetric data-encryption key may be used to protect data in storage. The originator-usage period of a symmetric data-encryption key applies to the use of that key to encrypt information for storage. The recipientusage-period applies to the retrieval and decryption of the data when needed. This period may extend over many years.

1454 1455 1456 1457

The amount of information that is encrypted using a single data-encryption key should be limited so that a compromise of the key does not expose vast amounts of information (e.g., limited to the encryption of no more than a single file or disk sector; see Sec. 4.3).

1458 1459 1460 1461 1462

When establishing the recipient-usage period, the length of time during which the data needs to be available and confidential needs to be considered. If the recipient-usage period is very long, it may become necessary to re-encrypt the data using a different data-encryption key and/or stronger algorithm (see Sec. 4.6.5).

1463 1464 1465 1466

Cryptoperiod: The originator-usage period recommended for the encryption of data should be measured in the amount of data to be encrypted using a single key, whereas the recipient-usage period needs to be set in accordance with the length of time for which the data needs to be confidential and/or available.

1467 1468

•

Key storage (for operational, backup, and archive storage) 22. Symmetric key-wrapping/unwrapping key

1469 1470 1471 1472 1473 1474 1475

Type considerations: A symmetric key-wrapping/unwrapping key is used to protect one or more keys in storage (e.g., other symmetric keys or private asymmetric keys used for protecting storage or communications). The originatorusage period of a symmetric key-wrapping key applies to the use of that key for wrapping keys. The recipient-usage-period applies to the retrieval and unwrapping of a wrapped key when needed. This period may extend over many years.

1476 1477 1478

The number of keys that are wrapped using a single key-wrapping key should be limited so that a compromise of the key does not expose vast numbers of wrapped keys (see Sec. 4.3).

1479 1480 1481

When establishing the recipient-usage period, the length of time during which the wrapped keys need to be available needs to be considered (e.g., to decrypt data, unwrap other keys, protect communications).

1482 1483 1484 1485 1486

Cryptoperiod: The originator-usage period recommended for a symmetric keywrapping/unwrapping key should be measured in the number of keys to be wrapped using a key-wrapping key, whereas the recipient-usage period needs to be set in accordance with the length of time for which the wrapped keys need to be available.

36

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

1487

Recommendation for Key Management Part 1 — General

23. Public key-wrapping key

1488 1489 1490 1491 1492 1493 1494

Type considerations: A public key-wrapping key is used to protect one or more keys in storage (e.g., symmetric keys or private asymmetric keys used for protecting storage or communications). The cryptoperiod of a public keywrapping key applies to the use of that key for wrapping keys. The number of keys that are wrapped using a single key-wrapping key should be limited so that a compromise of the key does not expose vast numbers of wrapped keys (see Sec. 4.3).

1495 1496 1497

Cryptoperiod: The cryptoperiod suggested for a public key-wrapping key should be measured in the number of keys to be wrapped using a single key-wrapping key.

1498

24. Private key-unwrapping key

1499 1500 1501 1502

Type considerations: A private key-unwrapping key is used to unwrap keys in storage that were wrapped by the corresponding public key-wrapping key. The cryptoperiod of this key applies to the retrieval and unwrapping of a wrapped key when needed. This period may extend over many years.

1503 1504 1505

When establishing the cryptoperiod, the length of time for which the wrapped keys need to be available needs to be considered (e.g., to decrypt data, unwrap other keys, protect communications).

1506 1507 1508

Cryptoperiod: The cryptoperiod of a private key-unwrapping key needs to be set in accordance with the length of time for which the wrapped keys need to be available.

1509

25. Public encapsulation key

1510 1511 1512 1513 1514 1515 1516

Type considerations: A public encapsulation key may be used to encapsulate symmetric keys for storage applications (e.g., a data encryption/decryption key to be used for protecting stored data or a key-wrapping key to protect other keys). The cryptoperiod of the public encapsulation key applies to the use of that key for encapsulating symmetric keys. The number of keys that are encapsulated using a single encapsulation key should be limited so that a compromise of the key does not expose vast numbers of encapsulated keys (see Sec. 4.3).

1517 1518

Cryptoperiod: The cryptoperiod suggested for a public encapsulation key should be measured in the number of keys to be encapsulated using that key.

1519

26. Private decapsulation key

1520 1521 1522

Type Considerations: A private decapsulation key is used by the owner of the encapsulation/decapsulation key pair to decapsulate symmetric keys that were encapsulated using the corresponding public encapsulation key.

1523 1524 1525

Cryptoperiod: The cryptoperiod of the private decapsulation key may need to be longer than the cryptoperiod of the corresponding public encapsulation key. The cryptoperiod of the private decapsulation key is the length of time during which 37

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

1526 1527 1528 1529

Recommendation for Key Management Part 1 — General

any key that was encapsulated using the corresponding public key needs to be decapsulated. •

Authorization keys 27. Symmetric authorization key

1530 1531 1532 1533 1534 1535 1536

Type Considerations: A symmetric authorization key may be used for an extended period of time, depending on the resources that are protected and the role of the entity authorized for access. For this key type, the originator-usage period and the recipient-usage period are the same. The primary considerations in establishing the cryptoperiod for a symmetric authorization key include the strength of the key, the adequacy of the cryptographic method, and the adequacy of the keyprotection mechanisms and procedures.

1537 1538

Cryptoperiod: The cryptoperiod of a symmetric authorization key should be no more than two years.

1539

28. Private authorization key

1540 1541 1542 1543 1544 1545 1546

Type Considerations: A private authorization key may be used for an extended period of time, depending on the resources that are protected and the role of the entity authorized for access. The primary considerations in establishing the cryptoperiod for a private authorization key includes the strength of the key, the adequacy of the cryptographic method, and the adequacy of the key-protection mechanisms and procedures. The cryptoperiod of a private authorization key and its corresponding public key shall be the same.

1547 1548 1549 1550

Cryptoperiod: Given an expectation that the security of the key-storage and use environment will increase as the sensitivity and criticality of the authorization processes increases, the cryptoperiod for a private authorization key should be no more than two years.

1551

29. Public authorization key

1552 1553 1554

Type Considerations: A public authorization key is the public element of an asymmetric key pair that is used to verify privileges for an entity that possesses the corresponding private key.

1555 1556

Cryptoperiod: The cryptoperiod of a public authorization key shall be no more than two years.

1557 1558 1559 1560

Table 1 provides suggested cryptoperiods for each key type. Longer or shorter cryptoperiods may be warranted, depending on the application and environment in which the keys will be used. However, when assigning a longer cryptoperiod, serious consideration should be given to the risks associated with doing so (see Sec. 4.3.1).

38

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

1561

Recommendation for Key Management Part 1 — General

Table 1. Suggested cryptoperiods for key types Cryptoperiod Key Type

Originator-Usage Period (OUP)

Recipient-Usage Period

Digital Signatures 1. Private signature key

1 to 3 years

2. Public signature-verification key

−

Several years (depending on key size) Authentication

3. Symmetric authentication key

< 2 years

< OUP + 3 years

4. Private authentication key

1 to 2 years

5. Public authentication key

1 to 2 years Random Bit Generation

6. Symmetric RBG keys

See SP 800-90A

−

Key Derivation 7. Symmetric key-derivation key

About 1 year

−

Key Establishment (automated) 8. Symmetric key-wrapping/unwrapping key

< 2 years

< OUP + 3 years

9. Public key-transport key

1 to 2 years

10. Private key-transport key

< 2 years 16

11. Symmetric key-agreement key

1 to 2 years 17

12. Public static key-agreement key

1 to 2 years

13. Private static key-agreement key

1 to 2 years 18

14. Public ephemeral key-agreement key

One key-agreement transaction

15. Private ephemeral key-agreement key

One key-agreement transaction

16. Public static encapsulation key

1-2 years

17. Private static decapsulation key

< 2 years 19

18. Public ephemeral encapsulation key

One key-establishment transaction

19. Private ephemeral decapsulation key

One key-establishment transaction

Data Encryption/Decryption 20. Symmetric data encryption/decryption key (data in transit)

< 2 years

< OUP + 3 years

21. Symmetric data encryption/decryption key (data at rest)

Limit to the amount of data to be encrypted

Until the data no longer needs to be available and/or confidential

Key Storage (for operational, backup, and archive storage) 16 In certain email applications where received messages are stored and decrypted at a later time, the cryptoperiod of a private key-transport key may exceed the cryptoperiod of the public key-transport key. 17 In certain email applications where received messages are stored and decrypted at a later time, the key’s recipient-usage period key may exceed the originator-usage period. 18 In certain email applications where received messages are stored and decrypted at a later time, the cryptoperiod of a private static keyagreement key may exceed the cryptoperiod of the corresponding public static key-agreement key. 19 In certain applications where encapsulated data is stored and decapsulated, the cryptoperiod of a private static decapsulation key may exceed the cryptoperiod of the corresponding public static encapsulation key.

39

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General Cryptoperiod

Key Type 22. Symmetric key-wrapping/unwrapping key

Originator-Usage Period (OUP)

Recipient-Usage Period

Limit to the number of keys to be wrapped

Until the wrapped keys are no longer needed

23. Public key-wrapping key

Limit to the number of keys to be wrapped

24.Private key-unwrapping key

Until the wrapped keys are no longer needed

25. Public encapsulation key

Limit to the number of keys to be encapsulated

26.Private decapsulation key

Until the encapsulated keys are no longer needed Authorization

27. Symmetric authorization key

< 2 years

28. Private authorization key

< 2 years

29. Public authorization key

< 2 years

1562

4.4. Assurances

1563 1564 1565

When keying material (e.g., keys, IVs, and algorithm parameters) is stored or distributed, it may pass through unprotected environments. In such cases, specific assurances are required before the keying material is used to perform normal cryptographic operations.

1566

4.4.1. Assurance of Integrity (Integrity Protection)

1567

Assurance of integrity shall be obtained prior to using all keying material.

1568 1569 1570 1571 1572 1573 1574

At a minimum, assurance of integrity shall be obtained by verifying that the keying material has the appropriate format and came from an authorized source. Additional assurance of integrity should be obtained through the proper use of error detection codes, MACs, and digital signatures to provide assurance that keying material has not changed since it was generated. . For example, a MAC could be generated on stored key information to provide assurance that the key information has not changed while in storage, and the MAC could be stored with the key information for easy access.

1575

4.4.2. Assurance of Algorithm Parameter Validity

1576 1577 1578 1579 1580 1581 1582 1583 1584 1585

Algorithm parameters are used with some algorithms to generate keys, create digital signatures, and establish keying material. Invalid algorithm parameters could void all intended security for all entities using the algorithms. Methods for obtaining assurance of algorithm-parameter validity for digital signature algorithms are provided in [SP 800-89]. Methods for obtaining assurance of algorithm-parameter validity for finite-field and ellipticcurve discrete-log key-agreement algorithms are provided in [SP 800-56A]. Approved algorithm parameters for key encapsulation are specified in the relevant algorithm specification (e.g., [FIPS 203] for ML-KEM and [FIPS 204] for ML-DSA). If a public key is certified by a CA for these algorithms, the CA could obtain this assurance during the certification process, and users could obtain assurance by verifying the certificates. 40

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1586 1587

Otherwise, the key-pair owner and any relying parties are responsible for obtaining the assurance.

1588

4.4.3. Assurance of Public-Key Validity

1589

Assurance of public-key validity shall be obtained on all public keys before using them.

1590 1591 1592 1593 1594 1595 1596 1597 1598

Assurance of public-key validity gives the user confidence that the public key is correct. This reduces the probability of using weak or corrupted keys. Invalid public keys could result in voiding the intended security, including the security of the operation (e.g., digital signature generation or key establishment), leaking some or all information from the owner’s private key, and leaking some or all information about a private key that is combined with an invalid public key (e.g., when key agreement or public-key encryption is performed). One of several ways to obtain assurance of public-key validity is for an entity to verify certain mathematical properties that the public key should have. Another way is to obtain assurance from a trusted third party (e.g., a CA) that the trusted party validated the properties.

1599 1600 1601 1602 1603 1604 1605

Methods for obtaining assurance of public-key validity for the digital signature algorithms specified in [FIPS 186-5], [FIPS 204], [FIPS 205], and [SP 800-208] are provided in [SP 800-89]. Methods for obtaining this assurance for finite-field and elliptic-curve discrete-log keyestablishment schemes are provided in [SP 800-56A]. Methods for obtaining assurance of (partial) public-key validity for RSA key-establishment schemes are provided in [SP 800-56B]. Methods for obtaining public-key validity for a KEM are discussed in the relevant algorithm specification (e.g., [FIPS 203] for ML-KEM).

1606

4.4.4. Assurance of Private-Key Possession

1607 1608 1609 1610 1611 1612 1613

Assurance of static (i.e., long-term) private-key possession shall be obtained before using the corresponding static public key. Assurance of public-key validity shall always be obtained prior to or concurrently with assurance of possession of the private key. Assurance of possession of the correct private key shall be obtained by the key-pair owner (e.g., ensuring that it is available and has not been modified before use). Entities that receive a public key shall obtain assurance that the key-pair owner possesses the private key corresponding to the received public key.

1614 1615 1616 1617 1618

For specific details regarding assurance of the possession of private key-establishment keys, see [SP 800-56A], [SP 800-56B], and [SP 800-227]. For specific details regarding assurance of the possession of private digital signature keys, see [SP 800-89]. For public keys that are certified by a CA, the CA could obtain this assurance during the certification process. Otherwise, the owner and relying parties are responsible for obtaining the assurance.

1619

4.4.5. Key Confirmation

1620 1621 1622

Key establishment is the process by which keying material is securely established among entities for subsequent use, usually between pairs of entities. Key confirmation is a procedure used to provide assurance that these entities actually share the same keying material. This 41

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1623 1624 1625 1626

procedure is highly recommended and can be performed either within a key-establishment process or external to the key-establishment process. For discussions about key confirmation performed during automated key establishment, see [SP 800-56A], [SP 800-56B], and [SP 800227].

1627

4.5. Compromise of Keys and Other Keying Material

1628 1629 1630 1631 1632 1633 1634 1635

Information protected by cryptographic mechanisms is only secure if the algorithms remain strong and the keys have not been compromised. It is the responsibility of an owner of a private asymmetric or secret symmetric key to protect the confidentiality of that key. Key compromise occurs when the protective mechanisms for a key fail (e.g., the confidentiality, integrity, or association of the key to its owner fail; see Sec. 5), and the key can no longer be trusted to provide the required security. Reporting a possible key compromise is the responsibility of anyone who suspects that a key has been compromised (e.g., the key’s owner observes that the data protected by that key has been compromised).

1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647

When a key is compromised, all use of the key to apply cryptographic protection to information (e.g., compute a digital signature or encrypt information) shall cease, and the compromised key shall be revoked (see Sec. 7.3.5). However, the continued use of the key under controlled circumstances to remove or verify the protections (e.g., to decrypt or verify a digital signature) may be warranted, depending on the risks of continued use and the organization’s key management policy (see [SP 800-57p2]). The continued use of a compromised key shall be limited to processing information that has already been protected. In this case, the entity that uses the information must be made fully aware of the risks involved. Limiting the cryptoperiod of the key limits the amount of material that would be compromised (i.e., exposed) if the key were compromised. Using different keys for different purposes (e.g., different applications or cryptographic mechanisms) and limiting the amount of information protected by a single key also achieves this purpose (see Sec. 4.3).

1648

4.5.1. Implications

1649

The compromise of a key has the following implications:

1650 1651 1652 1653 1654 1655 1656

1. The unauthorized disclosure of a key that is used to provide confidentiality protection (i.e., via encryption) means that all information encrypted by that key could be determined by unauthorized entities. For example, if a symmetric data-encryption key is compromised, an unauthorized entity could use the key to decrypt past or future encrypted information (i.e., the information is no longer confidential among the authorized entities). In addition, a compromised key could be used by an adversary to encrypt information of the adversary’s choosing, thus providing false information.

1657 1658 1659 1660 1661

The unauthorized disclosure of a private signature key means that the integrity and non-repudiation qualities of all data signed by that key are suspect. An unauthorized party in possession of the private key could sign false information and make it appear to be valid. If it can be shown that the signed data was protected by other mechanisms (e.g., physical security) from a time before the compromise, the signature may still 42

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672

have some value. For example, if a signed message was received on day 1 and it was later determined that the private signing key was compromised on day 15, the receiver may still have confidence that the message is valid because it was maintained in the receiver’s possession before day 15. Cryptographic timestamping may also provide protection for messages signed before the private signature key was compromised. However, the security provided by these other mechanisms is now critical to the security of the signature. In addition, the authenticity of the signed message may be questioned, since the private signature key may have been disclosed to the message receiver or some other entity who then altered the message in some way. The disclosure of a CA’s private signature key means that an adversary can create fraudulent certificates and certificate revocation lists (CRLs).

1673 1674 1675 1676 1677

2. A compromise of the integrity of a key means that the key has been accidentally or deliberately modified or another key has been substituted. This includes a deletion (i.e., non-availability) of the key. The substitution or modification of a key used to provide integrity protection calls into question the integrity of all information protected by that key.

1678 1679 1680 1681

3. A compromise of a key’s usage or application association means that the key could be used for the wrong purpose (e.g., for key establishment instead of digital signatures) or for the wrong application and could result in the compromise of information protected by the key.

1682 1683 1684

4. A compromise of a key’s association with the owner or another entity means that the identity of the entity cannot be assured (i.e., one does not know who the entity really is).

1685 1686 1687 1688

5. A compromise of a key’s association with other information means that there is no association at all or that the association is with the wrong information. This could cause cryptographic services to fail, information to be lost, or the security of the information to be compromised.

1689

4.5.2. Protective Measures

1690 1691

Certain protective measures may be used to minimize the likelihood or consequences of a key compromise. The following is recommended:

1692 1693

1. Limit the amount of time that a secret symmetric key or asymmetric private key is in plaintext form;

1694 1695

2. Prevent humans from viewing plaintext secret symmetric keys and asymmetric private keys;

1696 1697 1698

3. Restrict plaintext secret keys and private keys to physically protected “containers,” including key generators, key-transport devices, key loaders, cryptographic modules, hardware security modules (HSMs), and key-storage devices;

43

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1699 1700 1701 1702

4. Use integrity checks to ensure that the integrity of a key or its association with other data has not been compromised (e.g., keys may be wrapped in such a manner that unauthorized modifications to the wrapped key or the key’s metadata will be detected);

1703 1704

5. Employ key confirmation to help ensure that the proper key was established (see [SP 800-56A], [SP 800-56B], [SP 800-175B], and [SP 800-227]);

1705 1706

6. Establish an accountability system that keeps track of each access to secret symmetric keys and asymmetric private keys in plaintext form;

1707 1708

7. Provide a cryptographic integrity check on the key (e.g., using a MAC or digital signature);

1709

8. Use trusted timestamps for signed data;

1710

9. Destroy keys as soon as they are no longer needed; and

1711

10. Create a compromise-recovery plan, especially in the case of a compromised CA key.

1712 1713 1714 1715 1716 1717 1718 1719

The worst form of key compromise is one that is not detected. Nevertheless, even in this case, certain protective measures can be taken. A key-management system should be designed to mitigate the negative effects of a key compromise; the system should be designed so that the compromise of a single key compromises as little data as possible (see [SP 800-152]). For example, a single cryptographic key could be used to protect the data of only a single human entity or a limited number of such entities. Systems often have alternative methods to authenticate communicating entities that do not rely solely on the possession of keys. The intent is to avoid building a system with catastrophic weaknesses.

1720 1721 1722 1723 1724

A compromise-recovery plan is essential for restoring cryptographic security services in the event of a key compromise. A compromise-recovery plan shall be documented and easily accessible. The plan may be included in a Key-Management Practices Statement (see [SP 80057p2]). If not, the Key-Management Practices Statement should reference the compromiserecovery plan.

1725 1726 1727 1728 1729 1730 1731

Although compromise recovery is primarily a local action, the entire community that uses the system or equipment is affected by the repercussions. Therefore, compromise-recovery procedures should include the community at large. For example, recovery from the compromise of a root CA’s private signature key requires all entities that use the infrastructure to obtain and install a new trust anchor certificate. Typically, this involves physical procedures that are expensive to implement, so elaborate precautions to avoid compromise may be justified.

1732

The compromise-recovery plan should address the following topics:

1733 1734

•

The identification of the personnel to notify and what the notification should contain (e.g., whether specific keys or the certificate-generation process was compromised);

1735

•

The identification of the personnel to perform the recovery actions;

1736

•

The method for obtaining a new key (i.e., re-keying);

44

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1737 1738

•

The inventory of all cryptographic keys (e.g., the location of all keys and certificates in a system);

1739

•

The education of all appropriate personnel on the compromise-recovery procedures;

1740 1741

•

The policies requiring that key-revocation checking be performed to minimize the effect of a compromise;

1742 1743

•

The monitoring of the re-keying operations to ensure that all required operations are performed for all affected keys; and

1744

•

Other compromise-recovery procedures, such as:

1745

o A physical inspection of the equipment,

1746 1747

o The identification of all information that may be compromised as a result of the incident,

1748 1749

o The identification of all signatures that may be invalid due to the compromise of a signing key, and

1750

o The distribution of new keying material, if required.

1751

4.6. Guidelines for Cryptographic Algorithm and Key-Size Selection

1752 1753 1754 1755 1756

This section discusses the selection of appropriate algorithms and key sizes to provide adequate protection for 1) the expected lifetime of a system and 2) any sensitive data protected by that system during the expected lifetime of the data. Cryptographic algorithms that provide the security services identified in Sec. 2 are specified or adopted in FIPS and NIST recommendations. Some of these algorithms specify the use of several key sizes.

1757

4.6.1. Cryptographic Algorithm Security Strengths

1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769

Cryptographic algorithms can provide different security strengths, depending on the algorithm and key size used (whenever keys are required by the algorithm). In previous versions of this document, the estimated (classical) security strength (s) that an algorithm or system could provide is defined in terms of the amount of work (i.e., the number of operations) that is required to break the algorithm or system (i.e., the amount of work to break the algorithm requires 2s operations of some kind, where s = 112, 128, 192, or 256 bits). However, cryptanalytic advances (e.g., in factoring algorithms, general discrete-logarithm attacks, and elliptic-curve discrete-logarithm attacks) and the potential advent of quantum computing have brought into question the use of a single number to represent the security afforded by designating the same security strength for different algorithm types. In 2016, a NIST call for the submission of post-quantum algorithms categorized security strength in terms of the computational resources needed by an attacker to break a block cipher

45

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1770 1771

algorithm or hash function, essentially considering both classical and quantum computers. Listed in order of increasing strength, these security categories 20 are:

1772 1773

1. Secure against an attacker that is presumed to lack the resources needed for a key search of a block cipher algorithm with a 128-bit key (e.g., AES-128).

1774 1775

2. Secure against an attacker that is presumed to lack the resources needed for a collision search on a 256-bit hash function (e.g., SHA-256, SHA3-256).

1776 1777

3. Secure against an attacker that is presumed to lack the resources needed for a key search of a block cipher algorithm with a 192-bit key (e.g., AES-192).

1778 1779

4. Secure against an attacker that is presumed to lack the resources needed for a collision search on a 384-bit hash function (e.g., SHA-384, SHA3-384).

1780 1781

5. Secure against an attacker that is presumed to lack the resources needed for a key search of a block cipher algorithm with a 256-bit key (e.g., AES-256).

1782

Table 2. Security strength categories for post-quantum algorithms Security Category 1 2 3 4 5

Minimum Attack Cost

Example

Same as key search on a block cipher with a 128-bit key Same as collision search on a 256-bit hash function Same as key search on a block cipher with a 192-bit key Same as collision search on a 384-bit hash function Same as key search on a block cipher with a 256-bit key

AES-128 SHA-256 AES-192 SHA3-384 AES-256

1783 1784 1785

The use of strong cryptographic algorithms is critical for cryptographic security. However, their implementation and use are also of vital concern, since algorithms may unintentionally be implemented in a manner that leaks information about the key.

1786 1787 1788 1789 1790 1791 1792

The approved symmetric-key encryption algorithms (e.g., AES and Ascon-AEAD128) and public-key (i.e., asymmetric-key) algorithms require the use of cryptographic keys. Securitystrength estimates were made under the assumption that the keys are a specified length and are generated and handled in accordance with specific rules (e.g., the keys are generated using RBGs that were seeded with sufficient entropy and meet certain criteria). However, these rules are often not followed, and the security provided to the data protected by those keys may be somewhat less than the security-strength estimates provided (see Sec. 4.6.2).

1793 1794 1795 1796 1797 1798

Section 4.6.1.1 discusses the maximum security strengths that can be provided by the approved symmetric-key algorithms (e.g., used for encryption and message authentication). Section 4.6.1.2 discusses the maximum security strengths that can be provided by the classical asymmetric-key algorithms, while Sec. 4.6.1.3 addresses the security strengths for the approved quantum-resistant asymmetric-key algorithms. Section 4.6.1.4 discusses the security strengths of hash functions, XOFs, and their applications.

20 Appendix C discusses the use of security categories.

46

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1799

4.6.1.1. Security Strengths of Approved Symmetric-Key Algorithms

1800 1801

Table 3 provides the estimated maximum security strengths for symmetric-key algorithms and their key lengths.

1802

1. Column 1 indicates the security category (see Table 2).

1803 1804 1805 1806

2. Column 2 indicates the estimated maximum classical security strength (in bits) provided by the algorithms and key lengths listed in a particular row. The security strength is not necessarily the same as the length of the key due to attacks on algorithms that provide computational advantages.

1807 1808

3. Column 3 identifies the symmetric-key algorithms that can provide the security strength indicated in columns 1 or 2.

1809

Table 3. Security strengths of symmetric algorithms Security Strength (by category)

1 3 5

Classical Security Strength (by number of bits) ≤ 80 112 128 192 256

Symmetric-Key Algorithms 2TDEA 3TDEA 21 AES-128 and Ascon-AEAD128 AES-192 AES-256

1810 1811 1812 1813 1814 1815

The Triple Data Encryption Algorithm (TDEA) is specified in [SP 800-67] with three keys. 2TDEA is TDEA with two of the three keys being identical, and 3TDEA is TDEA with three different keys. As indicated by the orange background in Table 2, 2TDEA and 3TDEA are disallowed for applying cryptographic protection (e.g., using encryption) but may be used to process already protected information (e.g., using decryption). See [SP 800-131A] for more detailed information.

1816 1817

AES is specified in [FIPS 197] with three key sizes: 128, 192, and 256 bits. AES is used with the modes of operation specified in the [SP 800-38] series of publications.

1818 1819

Ascon-AEAD128 is specified for constrained devices in [SP 800-232] with a single 128-bit key size.

1820

4.6.1.2. Security Strengths of Approved Classical Asymmetric-Key Algorithms

1821 1822 1823

Table 4 provides the estimated maximum security strengths for the approved classical (i.e., non-quantum-resistant) asymmetric-key algorithms and their key lengths. The algorithms listed in this section do not satisfy the requirements for category 1 (see Table 2), since they

21 Although 3TDEA is listed as providing 112 bits of security strength, its use is now disallowed for applying cryptographic protection (see

[SP 800-131A]).

47

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1824 1825

can be broken with a quantum computer with relatively few resources compared to those needed for a key search on a 128-bit block cipher.

1826 1827

1. Column 1 indicates the estimated maximum classical security strength (in bits) provided by the algorithms and key lengths listed in a particular row.

1828 1829

2. Column 2 indicates the minimum size of the parameters associated with DSA, as specified in [FIPS 186-4].

1830 1831 1832 1833

3. Column 3 indicates the minimum size of the parameters associated with the standards that use finite-field cryptography (FFC) for key agreement. Examples of such algorithms include Diffie-Hellman (DH) and MQV key agreement, as defined in [SP 800-56A], where L is the size of the public key, and N is the size of the private key.

1834 1835 1836 1837

4. Column 4 indicates the value for k (the size of the modulus n) for algorithms based on integer-factorization cryptography (IFC). The predominant algorithm of this type is the RSA algorithm, which is approved in [FIPS 186-5] for digital signatures and in [SP 80056B] for key establishment. The value of k is commonly considered to be the key size.

1838 1839 1840 1841

5 Column 5 indicates the range of f (the size of n, where n is the order of the base point G) for algorithms based on elliptic-curve cryptography (ECC) that are specified for digital signatures in [FIPS 186-5] and for key establishment in [SP 800-56A]. The value of f is commonly considered to be the key size.

1842

Table 4. Security strengths of classical (non-quantum-resistant) asymmetric-key algorithms Classical Security Strength (by number of bits) ≤ 80 112 128 192 256

FFC DSA L = 1024 N = 160 L = 2048 N = 224 L = 3072 N = 256 L = 7680 N = 384 L = 15360 N = 512

FFC (DH, MQV) L = 1024 N = 160 L = 2048 N = 224 L = 3072 N = 256 L = 7680 N = 384 L = 15360 N = 512

IFC (RSA)

ECC (ECDSA, EdDSA, DH, MQV)

k = 1024

f = 160-223

k = 2048

f = 224-255

k = 3072

f = 256-383

k = 7680

f = 384-511

k = 15360

f = 512+

1843 1844 1845 1846 1847

For FFC and IFC algorithms, the listed key sizes do not necessarily match the key sizes approved in the source documents (i.e., [FIPS 186-5], [SP 800-56A], and [SP 800-56B]). That is, some key sizes may not be listed, or additional key sizes may be provided with their associated security strengths. However, estimated security strengths for FFC, IFC, and ECC algorithms may also be calculated using a formula in [IGD_B].

1848 1849 1850

The algorithm/key-size combinations shown in orange in Table 4 are no longer approved for applying cryptographic protection on Federal Government information (e.g., generating a digital signature). However, some flexibility is allowed for processing information that is

48

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1851 1852 1853

already protected at those security strengths (e.g., verifying digital signatures) if the receiving entity accepts the risks associated with doing so. See [SP 800-131A] for more detailed information.

1854

4.6.1.3. Security Strengths of Approved Quantum-Resistant Asymmetric-Key Algorithms

1855 1856

Table 5 provides the security categories for approved quantum-resistant asymmetric-key algorithms and their parameter sets.

1857 1858

1. Column 1 indicates the security category associated with the algorithms and parameter sets listed in a particular row.

1859 1860

2. Column 2 indicates the parameter sets for the ML-KEM key-encapsulation mechanism specified in [FIPS 203].

1861 1862

3. Column 3 indicates the parameter sets for the ML-DSA digital signature algorithm specified in [FIPS 204].

1863 1864

4. Column 4 indicates the parameter sets for the SLH-DSA digital signature algorithm specified in [FIPS 205].

1865 1866

5. Column 5 indicates the parameter sets for the LMS, HSS, XMSS, and XMSSMT digital signature algorithms in [SP 800-208].

1867

Table 5. Security categories for the quantum-resistant asymmetric-key algorithms Security Category

ML-KEM

1

ML-KEM-512

2

3

5

ML-DSA

ML-DSA-44

ML-KEM-768

ML-KEM-1024

SLH-DSA SLH-DSA-SHA2-128s SLH-DSA-SHAKE-128s SLH-DSA-SHA2-128f SLH-DSA-SHAKE-128f

ML-DSA-65

SLH-DSA-SHA2-192s SLH-DSA-SHAKE-192s SLH-DSA-SHA2-192f SLH-DSA-SHAKE-192f

ML-DSA-87

SLH-DSA-SHA2-256s SLH-DSA-SHAKE-256s SLH-DSA-SHA2-256f SLH-DSA-SHAKE-256f

49

LMS, HSS, XMSS, and XMSSMT

LMOTS_SHA256_N24 LMS_SHA256_M24 LMOTS_SHAKE_N24 LMS_SHAKE_M24 WOTSP with n=24 XMSS with n=24 XMSSMT with n=24 LMOTS_SHA256_N32 LMS_SHA256_M32 LMOTS_SHAKE_N32 LMS_SHAKE_M32 WOTSP with n=32 XMSS with n=32 XMSSMT with n=32

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1868

4.6.1.4. Security Strengths of Hash Functions, XOFs, and Their Applications

1869 1870 1871 1872

Cryptographic hashing is the process of transforming an input bit string of arbitrary length into an output hash value. Hash functions produce hash values of a fixed length, and XOFs produce a variable-length output (see Sec. 3.1). These approved hashing methods satisfy the following properties:

1873 1874

1. (Preimage-resistant) It is computationally infeasible to find an input that maps to any pre-specified output.

1875 1876

2. (Collision-resistant) It is computationally infeasible to find any two distinct inputs that map to the same output.

1877 1878 1879 1880 1881 1882 1883 1884 1885

The security strength of hash functions and XOFs is determined by the properties required by the application in which it is used. The appropriate hashing method should be determined by the algorithm, scheme, or application in which hashing is used and by the minimum securitystrength to be provided. For these applications, a cryptographic key is associated with the application and needs to be considered when determining the security strength afforded by the application.22 For example, when generating digital signatures, the minimum key length for the keys for a given security strength is provided in the FFC, IFC, and ECC columns of Table 4 in Sec. 4.6.1.2, while for HMAC, the key lengths are discussed at https://csrc.nist.gov/projects/hash-functions.

1886 1887 1888

Table 6 lists the approved hash functions and XOFs specified in [FIPS 180], [FIPS 202], and [SP 800-232], as well as various applications that require collision resistance (e.g., digital signatures), HMAC, KMAC, key derivation, and random bit generation.

1889 1890

1. Column 1 indicates the estimated maximum classical security strength (in bits) provided by the algorithms and (if appropriate) the key lengths for a particular row.

1891

2. Column 2 indicates the security category (see Table 2).

1892 1893 1894

3. Column 3 lists the hash functions and XOFs in [FIPS 180], [FIPS 202], and [SP 800-232] that provide the security strength identified in column 1 and/or column 2 for applications that require collision resistance (e.g., digital signatures).

1895 1896 1897

4. Column 4 lists the hash functions and XOFs that may be used in the hash-based applications that meet the security strength identified in column 1 and/or column 2. These applications require pre-image resistance.

1898 1899 1900 1901 1902 1903 1904

Notes about table entries are provided below the table and are indicated as superscripts within the table. For these applications, a cryptographic key is associated with the application and should be considered when determining the security strength afforded by the application. For example, for the generation of digital signatures, the minimum key length for the keys for a given security strength is provided in the FFC, IFC, and ECC columns of Table 4 in Sec. 4.6.1.2, while for HMAC, the key lengths are discussed at https://csrc.nist.gov/projects/hash-functions. 22 The cryptoperiod for a symmetric key includes both the originator-usage period and the recipient-usage period (see Sec. 4.3.5). Only the

originator-usage period is terminated.

50

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

1905

Recommendation for Key Management Part 1 — General

Table 6. Maximum security strengths for hash functions, XOFs, and their applications Classical Security Strength (by number of bits)

Applications Requiring Collision Resistance (e.g., digital signatures)

Security Strength (by category)

≤ 805

SHA-16

112

SHA-224,7 SHA512/224,7 SHA3-2247 1

SHA-17 SHA-256, SHA-512/256, SHA3-256, SHAKE1288, Ascon-hash256, AsconXOF128,9 AsconCXOF1289

128 2

192-224

1906

SHAKE1288, Asconhash256, Ascon-XOF128,10 AsconCXOF12810 SHA-224,7 SHA512/224,7 SHA3-2247

3 4

≥ 256

HMAC,1 KMAC,2 Key Derivation Functions,3 Random Bit Generation4

SHA-384, SHA3-384 SHA-512, SHA3-512, SHAKE25611

5

(SHA-256, SHA-512/256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512),12 SHAKE25611

Notes for Table 6:

1907 1908 1909 1910 1911 1912

1. HMAC uses a hash function and a key. The security strength provided by HMAC depends on the hash function used and the length of the key. The estimated security strength assumes that the length of the key and the security strength provided by the key-generation process are at least equal to the desired HMAC security strength (in bits). The HMAC specification [SP 800-224] requires the length of the key to be at least 128 bits.

1913 1914 1915 1916

2. KMAC is based on the KECCAK function specified in [FIPS 202] and uses a key. The estimated security strength provided by KMAC assumes that the length of the key and the security strength provided by the key-generation process are at least equal to the desired security strength (in bits).

1917 1918 1919

3. The security strength for key-derivation assumes that the shared secret computed during a key-agreement process or the preexisting key-derivation key can support the desired security strength.

1920 1921

4. The security strength for random bit generation assumes that the RBG has been instantiated with sufficient randomness to support the desired security strength. 51

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1922 1923 1924 1925 1926 1927 1928

5. Applications that provide less than 112 bits of security strength (i.e., ≤ 80, as shown in orange in Table 6) are not approved for applying cryptographic protection for Federal Government information (e.g., generating a digital signature or MAC value). However, some flexibility is allowed for processing information that is already protected at that security strength (e.g., verifying digital signatures or MAC values) if the receiving entity accepts the risks associated with doing so. See [SP 800-131A] for more detailed information.

1929 1930

6. SHA-1 has been demonstrated to provide less than 80 bits of security for digital signatures.

1931 1932 1933

7. SHA-1 and the 224-bit hash functions (highlighted in yellow in Table 6) are deprecated for use through 2030 and disallowed for applying cryptographic protection thereafter (see [SP 800-131A]).

1934 1935 1936 1937 1938 1939

8. The security provided by SHAKE128 depends on the size of the output (output_length). To obtain 128 bits of collision resistance (see column 3 in Table 6), at least 256 bits of output are required. For outputs less than 256 bits, the security strength provided is output_length/2. To obtain 128 bits of pre-image resistance (see column 4), at least 128 bits of output are required. For outputs less than 128 bits, the security strength provided is the output_length.

1940 1941

9. A collision resistance security strength of 128 bits is provided by Ascon-XOF128 and Ascon-CXOF128 only if the length of the output is at least 256 bits.

1942 1943

10. A pre-image security strength of 128 bits is provided by Ascon-XOF128 and AsconCXOF128 only if the length of the output is at least 128 bits.

1944 1945 1946 1947 1948 1949

11. The security provided by SHAKE256 also depends on the size of the output (output_length). To obtain 256 bits of collision resistance (see column 3 in Table 6), at least 512 bits of output are required. For outputs less than 512 bits, the security strength provided is output_length/2. To obtain 256 bits of pre-image resistance (see column 4), at least 256 bits of output are required. For outputs less than 256 bits, the security strength provided is the output_length.

1950 1951 1952

12. SHA-256, SHA-512/256, SHA-384, SHA-512, SHA3-256, SHA3-384, and SHA3-512 are category 5 if the key is at least 256 bits long and is generated at a security strength of at least 256 bits.

1953

4.6.2. Using Algorithm Suites and the Effective Security Strength

1954 1955 1956 1957 1958 1959 1960

Many applications require multiple cryptographic services (e.g., key establishment, confidentiality protection, integrity protection, and/or source authentication). A different algorithm and key could be used to provide each service (e.g., AES could be used for data encryption, and ML-DSA could be used to generate digital signatures for integrity protection), or multiple services could be provided by the same algorithm using the same or different keys (e.g., source authentication and integrity protection could be performed using ML-DSA to generate digital signatures). 52

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1961 1962 1963 1964 1965

Many services can also be provided by more than one algorithm (e.g., key establishment can be provided by RSA, DH, or ML-KEM). When several algorithms can be used to perform the same service, some algorithms are inherently more efficient because of their design (e.g., the use of both HMAC and digital signatures can provide integrity protection, but HMAC is designed to be more efficient).

1966 1967 1968 1969 1970

In many cases, a variety of key sizes may be available for an algorithm. For some of the algorithms (e.g., public-key algorithms, such as RSA), the use of key sizes that are larger than required may impact operations (e.g., larger keys may take longer to generate, require more memory and transmission bandwidth, and take longer to process data). However, the use of key sizes that are too small may not provide adequate security.

1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981

When selecting a block-cipher cryptographic algorithm (e.g., AES), the block size may also be a factor to consider, since the amount of security provided by several of the modes defined in the [SP 800-38] series depend on the block size. Algorithms of different strengths and key sizes may be used together for performance, availability, or interoperability reasons if sufficient protection is provided to the data to be protected. In general, the strength of cryptographic protection is determined by the weakest algorithm and key size used to provide the protection. A determination of the actual strength of the protection provided for data includes an analysis of not only the algorithms and key sizes used to apply cryptographic protections to the information but also the details of how the key and its predecessors were generated (e.g., the security strength supported by the RBG used during the generation of the key) and how the key was handled subsequent to generation.

1982 1983 1984 1985 1986 1987 1988 1989 1990

The handling of a key includes any processes that operated on the key (e.g., the key was used as input to some cryptographic operation). If a key that has been generated to provide a security strength of s bits is operated upon by a process that has a security strength of less than s bits, the key is reduced to the security strength of that process. For example, if a key has been generated by an RBG that provides output with a security strength of 256 bits, then the key and algorithm combination can provide 256 bits of security strength when the key is used with AES-256. However, if the key is wrapped using AES-128 (which can provide a maximum of only 128 bits of security strength), the security strength that can be provided by the 256-bit key is reduced to 128 bits, even though it is still used with AES-256.

1991 1992

The following is a list of several algorithm combinations and discussions on the security implications of the algorithm/key-size combination:

1993 1994 1995 1996 1997 1998 1999

1. When a key-establishment scheme is used to establish keying material for use with one or more symmetric-key algorithms (e.g., AES or HMAC), the security strength that can be supported by the keying material is determined by the weakest algorithm and key size used. For example, if ML-KEM 512 is used to establish a 256-bit AES key, no more than 128 bits of security can be provided for any information protected by that AES key, since the ML-KEM 512 key can only provide a maximum of 128 bits of security strength (see Table 5 in Sec. 4.6.1.3).

2000 2001

2. When a hash function and digital signature algorithm are used in combination to compute a digital signature, the security strength of the signature is determined by

53

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2002 2003 2004 2005

the weaker of the two algorithms. For example, if SHA-256 is used with ML-DSA 87 (which can support a security strength of 256 bits), the combination can provide no more than the 128 bits of security because SHA-256 can provide only 128 bits of security strength against collisions (see Table 6 in Sec. 4.6.1.4).

2006 2007 2008 2009

3. When an RBG is used to generate a key for a cryptographic algorithm that is intended to provide X bits of security, an approved RBG shall be used that supports at least X bits of security. For example, if AES-128 and its key are intended to provide 128 bits of security strength, then the RBG needs to support at least 128 bits of security.

2010 2011 2012 2013 2014

To support a given security strength, the combination of algorithms and key sizes must be carefully selected. For example, if 128 bits of security strength is required to protect data that is to be communicated and provided with confidentiality protection, integrity protection, and source authentication, the following selection of algorithms and key sizes may be appropriate:

2015

a. Select an RBG that supports at least a 128-bit security strength to generate keys.

2016 2017 2018 2019

b. Confidentiality: Encrypt the information using AES-128 and a key generated by the RBG in item a. Other AES key sizes would also be appropriate, but performance may be a little slower, and generating keys longer than 128 bits would not increase the amount of security provided.

2020 2021 2022 2023 2024 2025 2026

c. Integrity protection and source authentication: If only one cryptographic operation is preferred, use digital signatures. Select an algorithm for digital signatures from what is available to an application (e.g., ECDSA with at least a 256-bit key). SHA-256 or a larger hash function could be used to hash the data before generating the signature using the key. If more than one algorithm and key size is available, the selection may be based on algorithm performance, memory requirements, or other factors as long as the minimum requirements are met.

2027 2028 2029 2030 2031

d. Key establishment: Select a key-establishment scheme that is based on the application and environment (see [SP 800-56A], [SP 800-56B], and [FIPS 203]), the availability of an algorithm in an implementation, and its performance. Select a key size from Table 4 or Table 5 for an algorithm and key size that can provide at least 128 bits of security. For example, ML-KEM 512 might be a good choice if available.

2032 2033 2034 2035

Agencies that procure systems should consider the potential operational lifetime of the system. The agencies shall either select algorithms and key sizes that are expected to be secure during the entire system lifetime or should ensure that the algorithms and key sizes can be easily updated.

2036

4.6.3. Projected Algorithm and Security Strength Approval Status

2037 2038 2039 2040

Over time, cryptographic algorithms and their associated algorithm parameters (e.g., key lengths) may become more vulnerable to successful attacks, requiring a transition to stronger algorithms or longer key lengths. [SP 800-131A] provides the approval status of the NISTapproved cryptographic algorithms and their key lengths. 54

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

2041 2042

Recommendation for Key Management Part 1 — General

The minimum security strength required and algorithms to be used during the period in which specific data must be protected shall be obtained as follows:

2043 2044

•

Determine the security strength required for protecting data during the entire period of protection.

2045 2046 2047 2048

•

Using [SP 800-131A] and the tables in Sec. 4.6.1, select algorithms and key sizes of the same or greater strength than required. The security strength is determined not only by the algorithm used but also by the algorithm parameters and how the key was generated and handled (see Sec. 4.6.2).

2049 2050 2051

•

When keys are generated for a given algorithm by an RBG, they shall be generated using RBGs that support the security strength required by the algorithm (e.g., the design of the RBG and the entropy provided when seeding the RBG).

2052

4.6.4. Transitioning to New Algorithms and Key Sizes in Systems

2053 2054 2055 2056 2057 2058

Advances in computing capabilities, cryptographic research, and cryptanalytic techniques periodically create the need to replace algorithms or increase key sizes that no longer provide adequate security for their use cases. For example, the threats posed by future cryptographically relevant quantum computers to public-key cryptography demand an urgent migration to quantum-resistant cryptography. Such a transition is costly, takes time, raises interoperability issues, and disrupts operations.

2059 2060 2061 2062 2063 2064 2065 2066

A system that is designed with a flexible approach to transitioning is recommended. This is commonly referred to as “crypto agility” and describes the capabilities needed to replace and adapt cryptographic algorithms to achieve resiliency for protocols, applications, software, hardware, and infrastructures without interrupting the flow of a running system in order. Properly designed operational mechanisms that incorporate crypto agility considerations are needed to facilitate the transition to newer algorithms quickly, smoothly, and without introducing security breaches or operational disruptions. A more thorough discussion of crypto agility is available at https://csrc.nist.gov/Projects/crypto-agility.

2067 2068 2069 2070

This section of the document discusses specific algorithm and key size issues. Transitioning to new cryptographic algorithms and/or key sizes often directly affects enterprise key management. The impacts can range from minimal changes to accommodate larger key sizes to large-scale modifications of key types and their supporting key-establishment protocols.

2071 2072 2073 2074 2075 2076 2077 2078 2079

Section 4.6.1 provides estimates of the security strengths that can be supported by the currently approved classical and quantum-resistant cryptographic algorithms with recommended key sizes, and [SP 800-131A] provides the current algorithm approval status information and U.S. Federal Government transition recommendations. These resources can be used to help plan for transitions from existing cryptographic implementations to those that meet evolving cryptographic protection requirements. A flexible transition approach that uses implementations and applications that can most easily be adapted to new cryptographic security offerings that satisfy evolving requirements is strongly recommended. This section discusses some of the issues associated with cryptographic transition planning.

55

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

2080 2081 2082 2083 2084 2085

Recommendation for Key Management Part 1 — General

The estimated time period during which data protected by a specific cryptographic algorithm (and key size) remains secure is called the algorithm security lifetime. During this lifetime, the algorithm may be used to both apply cryptographic protection (e.g., encrypt and/or sign data) and process the protected information (e.g., decrypt and/or verify signed data), although the period allowed for applying protection could be shorter than the algorithm security lifetime (see Fig. 2).

2086 2087

Fig. 2. Algorithm originator-usage period example for symmetric keys

2088 2089 2090 2091 2092 2093 2094 2095

The algorithm is expected to provide adequate protection for the protected data during the algorithm’s security lifetime. The security lifetime projected when an algorithm is validated for protecting information may change during its usage period due to newly discovered cryptographic weaknesses, significant and previously unanticipated increases in cryptanalytic processing capabilities, or other changes to assumptions that were made when the security lifetime was projected. Such changes can result in the establishment of an earlier termination date for the security lifetime of an algorithm’s use for specified functions with a specified key size.

2096 2097 2098 2099 2100 2101 2102 2103 2104

Typically, an organization selects the cryptographic services that are needed for a particular application. Then, based on the algorithm security lifetime and the security life of the data that is to be protected, an algorithm and key-size suite that are sufficient to meet the security requirements are selected. The organization then establishes a key-management system that employs validated cryptographic products and provides the services required by the application. As an algorithm and/or key-size suite nears the end of its security lifetime, transitioning to a new algorithm and/or key-size suite should be planned with sufficient lead time to complete the transition within the period for applying cryptographic protection and the security lifetime of the replaced algorithm suite.

2105 2106 2107 2108 2109

When the algorithm or key size is determined to no longer provide the desired protection for information (e.g., the algorithm may have been “broken”), any information protected by the algorithm or key size must be considered suspect (i.e., the data may no longer be confidential, or the integrity cannot be assured). If the protected data is retained, it should be re-protected using an approved algorithm and key size that will protect the information for the remainder 56

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2110 2111 2112 2113 2114

of its security life. However, it should be assumed that encrypted information that was transmitted or was otherwise accessed by unauthorized parties during the security suite’s security lifetime could have been collected and retained for decryption at a later time. Any plaintext recovered during this period could be used to attempt matched plaintext-ciphertext attacks on the new algorithm suite following a transition.

2115 2116 2117 2118 2119 2120 2121

When using the tables in Sec. 4.6.1 to select an appropriate algorithm and key size, it is very important to take the expected security life of the data into consideration as well as the algorithm/key-size suite’s lifetime. As stated earlier, an algorithm and key size may be used to both apply cryptographic protection to data and process the protected data. Cryptographic protection should not be applied to data using a given algorithm and key size if the security life of the data extends beyond the end of the algorithm security lifetime (i.e., into the time frame during which the algorithm or key size is disallowed).

2122 2123 2124 2125 2126 2127 2128

For example, using Fig. 2, if the algorithm security lifetime of an encryption algorithm ends on December 31, 2050, then data with a security life of 10 years should not be encrypted using that algorithm after December 31, 2040. Instead, a different algorithm should be used whose lifetime covers the entire security life of the data. If the security life of the data is longer than originally expected, then the protection provided after 2050 may be less effective than required, and there is some risk that the confidentiality of the data may be compromised after 2050.

2129 2130 2131 2132 2133 2134 2135

When implementing cryptographic protection, the strongest algorithm and algorithmparameter set (which often includes the key size) that are appropriate to the application should be used to minimize the frequency of costly transitions. However, performance considerations also play a part in the selection process. For example, selecting some algorithms or unnecessarily large key sizes can have adverse performance effects (e.g., the algorithm may be unacceptably slow, or a communications protocol may not accommodate a candidate algorithm or key size).

2136 2137 2138 2139 2140 2141 2142 2143 2144 2145

The process of transitioning to a new algorithm or set of algorithm parameters may be as simple as selecting a more secure option in the set of security suites currently available to a system, or it can be as complex as building or acquiring an entirely new communications or authentication system. For example, systems, applications, or communications protocols currently being procured or in use may not accommodate or be sufficiently flexible to be configured to accommodate a candidate algorithm suite. The cost, complexity, and time required for transition can also depend on the scale of the transition. For example, transitioning to new algorithms and key sizes in a single storage system may have a limited set of constraints, while changing algorithms and algorithm parameters for implementation of TLS or SSH across a large enterprise may be much more involved.

2146 2147 2148 2149 2150 2151

The transition to a new cryptographic algorithm is not generally a simple process. The development of cryptographic modules that satisfy existing and emerging information communication, processing, and storage requirements need to be developed, subjected to security testing, and validated as meeting information security standards. Once replacement cryptography is available, enterprises need to plan and implement changes to or replacements of cryptographic libraries, implementation validation tools, hardware that 57

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2152 2153 2154 2155 2156 2157 2158

implements or accelerates algorithm performance, dependent operating system and application code, communications devices and protocols, and user and administrative procedures. If transitioning to newly developed replacement algorithms, cryptographic implementation standards, procedures, and best practice documentation need to be changed or replaced, as do installation, configuration, and administration documentation. In addition, the transitions need to be coordinated among organizations for which mutual cryptographic interoperability is required.

2159 2160 2161

When a decision is made to replace an algorithm, the time and resources necessary to implement the new cryptography depends largely on the organization’s readiness to make the transition in terms of factors such as:

2162 2163 2164

•

Knowing what systems, libraries, and applications employ the algorithm to be replaced (e.g., a quantum-vulnerable algorithm to be replaced by a quantumresistant algorithm)

2165 2166 2167

•

Understanding (by the organization’s management and technicians) the vulnerability of the organization to exposure or counterfeiting of its information in the event that specific categories of information are exposed to adversaries or the general public

2168 2169

•

Being able to evaluate the impact of the migration to new cryptography on existing information technology support contracts and information-sharing agreements

2170 2171 2172 2173

•

Understanding the performance requirements, sources, cost, delivery time frames, and integration requirements of additional hardware and software that might be required by changes to performance requirements imposed by differences between the new algorithms and those of the algorithms currently in use

2174 2175 2176 2177 2178 2179 2180 2181

In order to plan effectively for algorithm transition, an organization will need to understand the necessity and costs associated with making the transition within specific projected time frames. Decisions regarding expenditures generally require cost-benefit trade-offs. An organization cannot be expected to make decisions regarding the expenditure of resources for future technology transitions without understanding details regarding its readiness for the transitions. Resource expenditure decisions require quantitative information, and access to the necessary information requires a measurement of the organization’s readiness for the initiation and conduct of the transition.

2182 2183

Some specific examples of issues and processes that should be considered when adopting a new cryptographic algorithm include:

2184 2185 2186 2187 2188 2189 2190

1. The sensitivity of the information over time and the supporting information system’s lifetime: The sensitivity of the information that will need to be protected by the system for the lifetime of the new algorithms should be evaluated to determine the minimum security requirement for the system. Care should be taken not to underestimate the required lifetime of the system, the sensitivity of the information, or the period for which the information that it may need to protect will remain sensitive. Many decisions that were initially considered to be temporary or interim

58

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2191 2192

decisions about data sensitivity have since been proven to be inadequate (e.g., the sensitivity of the data persisted well beyond initial expectations).

2193 2194 2195 2196 2197 2198 2199 2200

2. Algorithm selection: New algorithms should be carefully selected to ensure that they meet or exceed the security requirements of the system. In general, it is relatively easy to select cryptographic algorithms and key sizes that offer high security. However, cryptographic experts should be consulted when making such decisions. Systems should offer algorithm-suite options that provide for future growth. In the case of government organizations, the use of validated cryptographic modules using federally approved algorithms with associated key sizes and operating modes is required (and recommended for other enterprises).

2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212

3. System design: A new system should be designed to meet minimum performance and security requirements and be sufficiently flexible to accommodate cryptographic updates. This is often a difficult task, since performance and security goals do not always align. All aspects of security (e.g., physical security, computer security, operational security, and personnel security) are involved. If the current system is to be modified to incorporate new algorithms, the consequences need to be analyzed. For example, the existing system and the protocols it employs for communication and storage may require significant modifications to accommodate the “footprints” of the new algorithms (e.g., key sizes or block sizes). In addition, the security measures (other than the cryptographic algorithms) that are retained from the system being upgraded should be reviewed to ensure that they will continue to be effective in the new system.

2213 2214 2215 2216

4. Pre-implementation evaluation: Strong cryptography may be poorly implemented. Therefore, changing to new cryptographic techniques should not be done without an evaluation to consider how effective and secure they are in the target system. In the case of federal systems, this means validation under [FIPS 140-3].

2217 2218

5. Validation: Algorithms shall be validated through the CAVP and implemented in a manner consistent with validated CMVP configurations.

2219 2220 2221 2222

6. Installation, operation, and support: Current system installation, operation, and support requirements should be reviewed for consistency with the suite to which transition is occurring, and adjustments to relevant plans, procedures, and documentation should be made and implemented.

2223 2224

7. Testing: All systems should undergo security and functional testing before they are deployed.

2225 2226 2227

8. Training: If the new system requires new or different tasks (e.g., key-management procedures) to be performed, then the individuals who will perform those tasks should be properly trained.

2228 2229 2230

9. System implementation and transition: Care should be taken to implement the system as closely as possible to the design. Any exceptions should be noted, and mitigation steps should be identified and scheduled. Implementation considerations

59

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2231 2232 2233

should include the means for maintaining the integrity of the algorithm and both the integrity and confidentiality of cryptographic keys, including physical and logical protection.

2234 2235 2236

10. Transition: A transition plan should be developed and followed so that the changeover from the old to the new system runs as smoothly as possible. The plan should include:

2237 2238 2239 2240

•

An initial phase in which all affected existing cryptographic implementations, contractual obligations for affected cryptographic provisioning installation, integration maintenance, support, upgrade and remedial change support, documentation support, and training support are identified;

2241 2242

•

A phase in which specific transition activities and funding requirements are identified and defined; and

2243 2244

•

An implementation phase in which the activities and responsible parties are scheduled and assigned.

2245 2246

11. Post-implementation evaluation: The system should be evaluated to verify that the implemented system meets the system’s security requirements.

2247

For additional considerations associated with a transition to new algorithms, see [CSWP15].

2248

4.6.5. Decrease in Security Over Time

2249 2250 2251 2252

Eventually, the security provided by an algorithm or key may be reduced or lost completely. For example, the algorithm or key length used may no longer offer adequate security due to improvements in computational capability or cryptanalysis. In this case, applying protection to “new” information should be performed using stronger algorithms or keys.

2253 2254 2255 2256 2257 2258

[SP 800-131A] categorizes the approval status of the NIST cryptographic algorithms as acceptable, deprecated, disallowed, or legacy use. Acceptable and deprecated mean that an algorithm, scheme, parameter choice, and/or key of a particular type, length, or strength is approved for use. However, a deprecated status means that there is some security risk in doing so (e.g., there is less assurance about the amount of security that may be provided by the cryptographic service).

2259 2260 2261 2262

When a cryptographic service using a cryptographic algorithm, scheme, parameter choice, and/or key of a particular type, length, or strength is disallowed (i.e., the use of the cryptographic service using one or more of these cryptographic elements is disallowed), the assigned cryptoperiod for the key is affected.

2263 2264 2265 2266 2267

•

The cryptoperiod assigned to the private key of an asymmetric key pair that is disallowed because of one or more of these cryptographic elements shall be terminated (e.g., a digital signature shall not be generated using any disallowed cryptographic element). The corresponding public key may continue to be used to process cryptographically protected information for which the protection was applied

60

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

when the cryptographic element was not disallowed (e.g., a signature may be verified). However, the use of the public key continues to be allowed for legacy use.

2268 2269 2270 2271 2272 2273 2274

Recommendation for Key Management Part 1 — General

•

The originator-usage period assigned to a symmetric key that is disallowed because of one or more of these cryptographic elements shall be terminated 23 (e.g., data shall not be encrypted using any disallowed cryptographic element). However, processing the protected information (e.g., decrypting ciphertext using the key) is allowed for legacy use.

2275 2276

In either case, a revocation notice should be made available about the revoked key or key pair. The revocation notice should include a timestamp to indicate the time of the revocation.

2277 2278 2279 2280

There are risks with using a cryptographic service that is only allowed for legacy use. A reduction in the security that is intended to be provided by an algorithm or key (i.e., as indicated by an approval status of deprecated or disallowed in [SP 800-131A]) has the following implications:

2281 2282 2283 2284 2285 2286 2287 2288 2289 2290

•

Encrypted information: The security of encrypted information that was available at any time to unauthorized entities in its encrypted form should be considered suspect. For example, keys that were transmitted in encrypted form (e.g., using a key-wrapping key or key-transport key and an algorithm or key length that is later broken) may need to be considered compromised, since an adversary could have saved the encrypted form of the keys for later decryption in case methods for breaking the algorithm are eventually found (see Sec. 4.5 for a discussion of key compromises). Even if the transmitted, encrypted information is subsequently re-encrypted for storage using a different key or algorithm, the information may already be compromised because of the weakness of the transmission algorithm or key.

2291 2292 2293 2294 2295

Encrypted information that was not “exposed” in this manner (e.g., not transmitted) may still be secure even though the encryption algorithm or key length no longer provides the initially required amount of protection. For example, if the encrypted form of the keys and the information protected by those keys was never transmitted, then the information may still be confidential.

2296 2297 2298 2299 2300 2301 2302 2303

The lessons to be learned are that an encryption mechanism used for information that will be available to unauthorized entities in its encrypted form (e.g., via transmission) should be provided with a high level of security protection, and the use of each key should be limited (i.e., the cryptoperiod should be short) so that a compromised key cannot be used to reveal very much information. If the algorithm itself is broken, 24 an adversary is forced to perform more work to decrypt the information when each key is used to encrypt a very limited amount of information. Section 4.3.6 discusses cryptoperiods.

23 The cryptoperiod for a symmetric key includes both the originator-usage period and the recipient-usage period (see Sec. 4.3.5). Only the

originator-usage period is terminated.

24 For example, it is easier to recover a key than to conduct an exhaustive search.

61

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314

•

Digital signatures on stored data that was originally transmitted: 25 Digital signatures may be computed on data prior to transmission and subsequent storage. In this case, both the signed data and the digital signature would be stored. If the security provided by the signature is later reduced (e.g., because of a break of the algorithm or because an adversary determined the key), the signature may still be valid if the stored data and its associated digital signature have been adequately protected from modification since a time prior to the decrease in strength (e.g., by applying a digital signature using a stronger algorithm or key). 26 Storage capabilities are being developed that employ cryptographic timestamps to store digitally signed data beyond the normal security life of the original signature mechanism or its keys (e.g., see [X995] and [ISO/IEC18014]).

2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326

•

Symmetric authentication codes on stored data that was originally transmitted: 27 Like digital signatures, symmetric authentication codes (i.e., MACs) may be computed on data prior to transmission and/or subsequent storage. If the received data and authentication code are stored as received, and the security of the authentication algorithm or key is disallowed for applying cryptographic protection (e.g., because of a weakness of the algorithm), the authentication code may still be valid if the stored data and its associated authentication code have been adequately protected from modification since a time prior to the disallowance (e.g., by applying another authentication code using a stronger algorithm or key). 28 Storage capabilities are being developed that employ cryptographic timestamps to store authenticated data beyond the normal security life of the original authentication mechanism or its keys (e.g., see [X995] and [ISO/IEC18014]).

2327

25 Digital signatures on data that is transmitted but not stored are not considered since their value is short-lived (e.g., the digital signature was intended to be used to detect errors introduced only during transmission). 26 See Sec. 4.5, item 1 for further discussion. 27 Symmetric authentication codes on data that is transmitted but not stored are not considered since their value is considered to be shortlived. 28 See Sec. 4.5, item 1 for further discussion.

62

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2328

5. Protection Requirements for Key Information

2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340

This section provides guidelines regarding the types of protection required for key information, which includes keying material and associated metadata and varies, depending on the type of key. The key information must be protected for the security services to be meaningful. A [FIPS 140-3]-validated cryptographic module may provide much of the protection needed, depending on its security level. However, additional protection is required (e.g., by access-control mechanisms in the operating system or by encryption and integrity protection for key information in an external database) when the key information exists external to a FIPS 140 cryptographic module. The type of protection needed depends on the type of key and the security service for which the key is used. [SP 800-152] provides recommendations for Federal Cryptographic Key Management Systems (FCKMSs) on the protection of key information when outside a FIPS 140-validated cryptographic module, as well as other key-management factors to be addressed.

2341

5.1. Protection and Assurance Requirements

2342 2343 2344 2345 2346 2347

Keying material should be (operationally) available for as long as the associated cryptographic service is required. Keys may be maintained within a cryptographic module while they are being actively used, or they may be stored externally (provided that proper protection is afforded) and recalled as needed. Some keys may need to be archived if required beyond the key’s cryptoperiod (see Sec. 4.3.4 and 4.3.5 for a discussion of the cryptoperiods for asymmetric and symmetric keys).

2348

The following protections and assurances may be required for the key information:

2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361

•

Confidentiality protection shall be provided for all secret key information (e.g., symmetric secret keys, asymmetric private keys, key shares, secret metadata). Public keys, algorithm parameters, and much of the metadata generally do not require confidentiality protection. Appropriate confidentiality protection is provided when secret key information exists within a validated cryptographic module that conforms to [FIPS 140-3] at a security level that is consistent with the [FIPS 199] impact level associated with the data to be protected by the key (see [SP 800-152]). When the secret or private key information is available outside of a cryptographic module, confidentiality protection shall be provided by encryption at an appropriate security strength (see [SP 800-152]) or by controlling access to the secret key information via physical means. 29 The security and operational impacts of specific confidentiality mechanisms vary. Sections 5.2.1.3 and 5.2.2.3 discuss the selection of appropriate confidentiality mechanisms.

2362 2363 2364

•

Integrity protection shall be provided for all key information. Integrity protection always requires checking the source and format of the received or retrieved key information (see Sec. 4.4.1). Appropriate integrity protection is provided when key

29 This may include storing the secret or private key information in a safe with limited access, logging all access to the key, regularly reviewing logs, and using automated alerts when unwarranted access is detected or suspected.

63

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

2365 2366 2367 2368 2369 2370 2371 2372 2373

Recommendation for Key Management Part 1 — General

information exists within a validated cryptographic module that conforms to [FIPS 140-3] at a security level that is consistent with the [FIPS 199] impact level associated with the data to be protected by the key (see [SP 800-152]). When key information is available outside of a cryptographic module, integrity protection shall be provided by appropriate cryptographic integrity mechanisms (e.g., cryptographic checksums, cryptographic hash functions, MACs, or digital signatures), non-cryptographic integrity mechanisms (e.g., CRCs or parity checks) (see Appendix A), or physical protection mechanisms. Sections 5.2.1.2 and 5.2.2.2 discuss the selection of appropriate integrity mechanisms.

2374 2375 2376 2377

•

Association protection shall be provided for a cryptographic security service by ensuring that the correct keying material is used to protect the correct data in the correct application or equipment. Sections 5.2.1.4 and 5.2.2.4 discuss the selection of appropriate association protection methods.

2378 2379 2380 2381 2382

•

Assurance of algorithm-parameter and public-key validity provides confidence that the parameters and keys used with cryptographic algorithms are correct (see Sec. 4.4.2 and 4.4.3). The selection of appropriate assurance mechanisms is discussed in [SP 800-56A], [FIPS 203], [FIPS 204], [FIPS 205], [SP 800-89], [SP 800-208], [SP 800227], and this document.

2383 2384

•

Assurance of private key possession provides assurance that the owner of a public key actually possesses the corresponding private key (see Sec. 4.4.4).

2385 2386 2387 2388

•

Availability protection shall be provided for all key information that needs to be available beyond its immediate use for protecting data (e.g., to decrypt or verify the continued integrity of the key information). This is accomplished by backing up or archiving the information (see Sec. 7.2.2.1 and 7.3.1).

2389 2390 2391 2392 2393 2394

The period of protection for key information depends on the type of key, the associated cryptographic service, and the length of time for which the cryptographic service is required. The period of protection includes the cryptoperiod of the key (see Sec. 4.3). The period of protection is not necessarily the same for integrity as it is for confidentiality. Integrity protection may only be required until a key is no longer used (but not yet destroyed), but confidentiality protection may be required until the key is actually destroyed.

2395

5.1.1. Summary of Protection and Assurance Requirements for Cryptographic Keys

2396 2397 2398

Table 7 provides a summary of the protection requirements for keys during distribution, key establishment, and storage. Methods for providing the necessary protection are discussed in Sec. 5.2.

2399

1. Column 1 (Key Type) identifies the key types.

2400 2401 2402 2403

2. Column 2 (Security Service) indicates the type of security services that are provided by the key in conjunction with a cryptographic technique. In this column, the word “support” means that the associated key is used to support the primary cryptographic services of confidentiality, integrity authentication, and source authentication. For 64

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2404 2405 2406 2407

example, a key-agreement key may support a confidentiality service by establishing the key used to provide confidentiality; an RBG key supports the use of cryptography because it is used to provide the random values for generating the keys to be used to cryptographically protect information.

2408 2409

3. Column 3 (Security Protection) indicates the type of protection required for the key (i.e., confidentiality, integrity, and/or availability).

2410 2411 2412 2413 2414

4. Column 4 (Association Protection) indicates the types of associations that need to be protected for that key, such as associating the key with the usage, application, authorized communications participants, or other indicated information (e.g., other keys). The association with algorithm parameters applies only to algorithms where they are used.

2415 2416 2417 2418 2419 2420 2421

5. Column 5 (Assurances Required) indicates whether the assurance of public-key validity and/or private-key possession need to be obtained, as defined in [SP 80056A], [SP 800-56B], [FIPS 203], [SP 800-89],30 [SP 800-227], and this recommendation. The assurance of public-key validity provides a degree of confidence that a key is correct (see Sec. 4.4.3). The assurance of private-key possession provides a degree of confidence that the entity providing a public key actually possessed the associated private key at some time (see Sec. 4.4.4).

2422 2423 2424 2425

6. Column 6 (Period of Protection) indicates the length of time for which the confidentiality, integrity and/or availability of the key needs to be maintained (see Sec. 4.3). Symmetric keys and private keys shall be destroyed at the end of their period of protection (see Sec. 7.3.4 and 8.4).

2426

Table 7. Protection requirements for cryptographic keys Key Type

Security Service

Security Protection

Association Protection

Assurances Required

Period of Protection

Private key possession

From generation until the end of the cryptoperiod

Digital Signatures Usage or application

Source authentication 1. Private signature key

Integrity authentication

Algorithm parameters (when used)

Confidentiality Integrity 31

Nonrepudiation

Public signatureverification key

30 SP 800-89 provides information about the assurances provided for digital signatures.

31 Integrity protection can be provided using a variety of means (see Sec. 4.2.1.2 and 4.2.2.2).

65

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025 Key Type

2. Public signatureverification key

Security Service

Recommendation for Key Management Part 1 — General

Security Protection

Association Protection

Period of Protection

Public key validity

From generation until no signatures need to be verified

Usage or application

Source authentication Integrity authentication

Assurances Required

Key-pair owner Algorithm parameters (when used)

Integrity Availability

Nonrepudiation

Private signature key Signed data Authentication

3. Symmetric authentication key

Identity authentication

Confidentiality

Integrity authentication

Availability

Usage or application

From generation until the identity or any protected data no longer needs to be authenticated

Other authorized entities

Integrity

Authenticated data Usage or application

4. Private authentication key

Identity authentication Integrity authentication

Public authentication key

Confidentiality Integrity

Private key possession

From generation until the end of the cryptoperiod

Public key validity

From generation until the identity or any protected data no longer needs to be authenticated

Algorithm parameters (when used) Usage or application Key pair owner

5. Public authentication key

Identity authentication Integrity authentication

Authenticated data

Integrity

Private authentication key

Availability

Algorithm parameters (when used) Random Bit Generation 6. Symmetric RBG keys

Support

Confidentiality

Usage or application

Integrity

66

From generation until replacement

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025 Key Type

Security Service

Recommendation for Key Management Part 1 — General

Security Protection

Association Protection

Assurances Required

Period of Protection

Key Derivation

7. Symmetric key-derivation/ master key

Support

From generation until the end of the cryptoperiod or the end of the lifetime of the derived keys, whichever is later

Usage or application

Confidentiality

Other authorized entities

Integrity

Derived keys Key Establishment (automated)

8. Symmetric key-wrapping key/unwrapping key

9. Public keytransport key

10. Private keytransport key

11. Symmetric key-agreement key

Confidentiality Support

Integrity

Other authorized entities

Availability

Wrapped keys Usage or application

Support

Integrity

Key pair owner Private keytransport key

Support

Confidentiality

Usage or application

Integrity

Encrypted keys

Availability

Public keytransport key

Usage or application

Confidentiality Support

From generation until the end of the cryptoperiod or until no wrapped keys require unwrapping, whichever is later

Usage or application

Integrity

Other authorized entities

Availability

67

Public key validity

From generation until the end of the cryptoperiod

Private key possession

From generation until no longer needed to decrypt keys From generation until the end of the cryptoperiod or until no longer needed to determine a key, whichever is later

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025 Key Type

Security Service

Recommendation for Key Management Part 1 — General

Security Protection

Association Protection

Assurances Required

Period of Protection

Public key validity

From generation until the end of the cryptoperiod or until no longer needed to determine a key, whichever is later

Private key possession

From generation until the end of the cryptoperiod or until no longer needed to determine a key, whichever is later

Public key validity

From generation until the keyagreement process is complete

Usage or application Key pair owner 12. Public static key-agreement key

Support

Algorithm parameters (when used)

Integrity

Private static key-agreement key Usage or application 13. Private static key-agreement key

Support

Algorithm parameters (when used)

Confidentiality Integrity

Public static keyagreement key Key pair owner

14. Public ephemeral keyagreement key

Private ephemeral keyagreement key Support

Integrity 32

Usage or application Algorithm parameters (when used) Usage or application

15. Private ephemeral keyagreement key

Support

Public ephemeral keyagreement key

Confidentiality Integrity

Algorithm parameters (when used)

From generation until the end of the keyagreement process After the end of the process, the key shall be destroyed

The confidentiality of public ephemeral key-agreement keys may not be protected during transmission. However, the key-agreement protocols may be designed to detect unauthorized substitutions and modifications of the transmitted public ephemeral keys. In this case, the protocols form the data integrity mechanism. 32

68

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025 Key Type

Security Service

Recommendation for Key Management Part 1 — General

Security Protection

Association Protection

Assurances Required

Period of Protection

Public key validity

From generation until the end of the cryptoperiod

Private key possession

From generation until the encapsulated keys no longer need to be decapsulated

Public key validity

From generation until the encapsulation process is complete for a single transaction

Usage or application 16. Public static encapsulation key

Key pair owner Support

Private static decapsulation key

Integrity

Algorithm parameters Usage or application 17. Private static decapsulation key

Encapsulated keys

Confidentiality Support

Integrity

Public static encapsulation key

Availability

Algorithm parameters Key pair owner 18. Public ephemeral encapsulation key

Support

Private ephemeral decapsulation key

Integrity

Usage or application Algorithm parameters Usage or application

19. Private ephemeral decapsulation key

Public ephemeral encapsulation key

Confidentiality Support

Integrity Availability

Algorithm parameters

Private key possession

From generation until the end of the decapsulation process After the end of the process, the key shall be destroyed

Data Encryption/Decryption 20. Symmetric data-encryption/ decryption key (data in transit)

Confidentiality Confidentiality

Usage or application

Integrity Availability

69

From generation until the end of the lifetime of the data or the end of

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025 Key Type

Security Service

Recommendation for Key Management Part 1 — General

Security Protection

Association Protection

Assurances Required

Other authorized entities

21. Symmetric data encryption/ decryption key: (data at rest)

Period of Protection the cryptoperiod, whichever is later

Plaintext/ Encrypted data Key Storage (for operational, backup, and archive storage)

22. Symmetric key-wrapping/ unwrapping key

23. Public keywrapping key

24.Private keyunwrapping key

Usage or application

Confidentiality Support

Integrity

Other authorized entities

Availability

Wrapped keys Usage or application

Support

Integrity

Key pair owner Private keyunwrapping key

Support

From generation until the end of the cryptoperiod or until no wrapped keys need to be unwrapped, whichever is later

Confidentiality

Usage or application

Integrity

Wrapped keys

Availability

Public keywrapping key

Public key validity

From generation until the end of the cryptoperiod

Private key possession

From generation until the end of the cryptoperiod of the wrapping key or no further keys need to be unwrapped, whichever is later

Public key validity

From generation until the end of the cryptoperiod

Usage or application 25. Public encapsulation key

Key pair owner Support

Private decapsulation key

Integrity

Algorithm parameters

70

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025 Key Type

Security Service

Recommendation for Key Management Part 1 — General

Security Protection

Association Protection

Assurances Required

Period of Protection

Private key possession

From generation until no keys need to be decapsulated

Usage or application 26.Private decapsulation key

Encapsulated keys

Confidentiality Support

Integrity

Public encapsulation key

Availability

Algorithm parameters Authorization 27. Symmetric authorization keys

Authorization

Usage or application

Confidentiality Integrity

From generation until the end of the cryptoperiod of the key

Other authorized entities Usage or application

28. Private authorization key

Authorization

Public authorization key

Confidentiality Integrity

Private key possession

From generation until the end of the cryptoperiod of the key pair

Public key validity

From generation until the end of the cryptoperiod of the key pair

Algorithm parameters (when used) Usage or application Key pair owner

29. Public authorization key

Authorization

Private authorization key

Integrity

Algorithm parameters (when used)

2427

5.1.2. Summary of Protection Requirements for Other Related Information

2428 2429 2430

Table 8 summarizes the protection requirements for other related information during distribution and storage. Mechanisms for providing the necessary protection are discussed in Sec. 5.2.

2431

1. Column 1 (Information Type) identifies the type of information.

71

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2432 2433

2. Column 2 (Security Service) indicates the type of security service provided by the information.

2434 2435

3. Column 3 (Security Protection) indicates the type of security protection required for the information.

2436 2437

4. Column 4 (Association Protection) indicates the relevant types of associations for each type of information.

2438 2439 2440 2441 2442

5. Column 5 (Assurance of Algorithm Parameter Validity) indicates the information for which assurance shall be obtained, as defined in [SP 800-56A], [SP 800-56B], [FIPS 203], [FIPS 204], [FIPS 205], [SP 800-208], [SP 800-227], and Sec. 4.4 of this document. Assurance of algorithm-parameter validity provides confidence that algorithm parameters are correct.

2443 2444 2445

6. Column 6 (Period of Protection) indicates the length of time for which the integrity and/or confidentiality of the information need to be maintained. The information shall be destroyed at the end of the period of protection (see Sec. 7.3.4).

2446

Table 8. Protection requirements for other related information

Information Type

Security Service

Algorithm parameters

Depends on the key associated with the parameters

Initialization vectors

Shared secrets (generated during key agreement)

Depends on the algorithm

Support

Security Protection

Integrity

Association Protection

Assurance of Algorithm Parameter Validity

Period of Protection

Yes

From generation until no longer needed

Usage or application Private and public keys

Availability

Integrity 33

Protected data

Availability

From generation until no longer needed to process the protected data From generation until the end of the transaction.

Confidentiality Integrity

33 IVs are not generally protected during transmission. However, the decryption system may be designed to detect or minimize the effect

of unauthorized substitutions and modifications to transmitted IVs. In this case, the decryption system is the data-integrity mechanism.

72

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Information Type

Seeds

Security Service

Support

Recommendation for Key Management Part 1 — General

Security Protection

Confidentiality Integrity

Association Protection

Usage or application

Usage or application Other public information

Support

Other authorized entities

Integrity

Data processed using a nonce

Usage or application Other secret information

Intermediate results

Support

Support

Other authorized entities

Confidentiality Integrity

Confidentiality Integrity

Data processed using the secret information

Usage or application

73

Assurance of Algorithm Parameter Validity

Period of Protection When used for random number generation, destroy immediately after use When used to regenerate keying material, destroy when no longer needed (e.g., at the end of the cryptoperiod of the keys) From generation until no longer needed to process data using the public information From generation until no longer needed to process data using the secret information From generation until no longer needed and the intermediate results are destroyed

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Information Type

Key-control information (e.g., IDs, purpose)

Random number

Password

Audit information

Security Service

Support

Support

Recommendation for Key Management Part 1 — General

Security Protection

Association Protection

Integrity

Key

Availability

Integrity

Confidentiality

Key derivation

Availability

Support

Integrity

Usage or application Owning entity

Integrity

Audited events

Access authorization

Key-control information/metadat a

Availability

Period of Protection From generation until the associated key is destroyed From generation until no longer needed, and the random number is destroyed

Confidentiality (depends on usage)

Identity authentication

Assurance of Algorithm Parameter Validity

From generation until replaced or no longer needed to authenticate the entity or to derive keys From generation until no longer needed

2447

5.2. Protection Mechanisms

2448 2449 2450 2451 2452

During the lifetime of key information, the key information is either “in transit” (e.g., is in the process of being distributed manually or using automated protocols to the authorized communication participants for use by those entities), “at rest” (e.g., the key information is in storage), or “in use.” In all cases, the key information shall be protected in accordance with Sec. 5.1.

2453 2454 2455

Keys that are in use shall reside (and be used) within appropriate cryptographic modules. A key being in use does not preclude that key from also being simultaneously in transit and/or in storage.

2456 2457 2458 2459

While in transit or in storage, the choice of protection mechanisms may vary. Although several methods of protection are provided in the following subsections, not all methods provide equal security. The method should be carefully selected. In addition, the mechanisms prescribed do not, by themselves, guarantee protection. The implementation and associated

74

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2460 2461

key management need to provide adequate security to prevent any feasible attack from being successful.

2462

5.2.1. Protection Mechanisms for Key Information in Transit

2463

Key information in transit may include keying material that is being distributed to:

2464 2465

•

Obtain a cryptographic service (e.g., to establish a key that will be used to provide confidentiality) (see Sec. 7.1.5) or

2466 2467

•

Back up or archive key information for possible use or recovery in the future (see Sec. 7.2.2 and 7.3.1) or

2468 2469

•

Recover the backed up or archived key information (see Sec. 7.2.2.2, 7.3.1, and Appendix B).

2470 2471 2472 2473 2474 2475 2476

This may be accomplished manually (i.e., via a trusted courier), in an automated fashion (i.e., using an automated communication protocol), or by some combination of manual and automated methods. For some protocols, the protections are provided by the protocol; in other cases, the protection of the key information is provided directly to the key information (e.g., the keying material is encrypted prior to transmission for decryption only by the receiving party). It is the responsibility of the originating party to apply protection mechanisms and the responsibility of the recipient to undo or check the mechanisms used.

2477

5.2.1.1. Availability

2478 2479 2480 2481 2482

Since communications may be garbled, intentionally altered, or destroyed, the availability of key information after transit cannot be assured using cryptographic methods alone. However, availability can be supported by redundant or multiple channels, store-and-forward systems (i.e., deletion by the sender only after confirmation of receipt by the intended recipient), error correction codes, and other non-cryptographic mechanisms.

2483 2484 2485

Communication systems should incorporate non-cryptographic mechanisms to ensure the availability of key information after transmission rather than relying on retransmission by the original sender.

2486

5.2.1.2. Integrity

2487 2488 2489 2490 2491 2492 2493

Integrity protection involves both the prevention and detection of modifications to information. The absolute prevention of modifications is not possible, but there are mechanisms (e.g., key-confirmation mechanisms) that can be used to detect modifications with a high probability. When modifications are detected, measures may be taken to restore the information to its unaltered form. Cryptographic mechanisms are often used for this purpose. Assurance of the integrity of received key information shall be obtained using one or more of the following methods:

2494

1. Manual method (physical protection is provided):

75

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506

Recommendation for Key Management Part 1 — General

a. An integrity mechanism is used to generate a “code” (e.g., CRC, MAC, or digital signature) on the key information to be distributed, and the resulting code is provided to the recipient along with the key information. If the received code is successfully verified by the recipient, then the recipient has assurance that the keying material has been received correctly. Otherwise, the key information is assumed to be corrupted. When using a cryptographic algorithm that uses a key to generate the code (e.g., a MAC or digital signature), the sender and recipient must know the appropriate keys for generating and verifying the code. A CRC may be used instead of a MAC or digital signature to generate the code, since the physical protection is only intended to protect against intentional modifications. -OR-

2507 2508 2509 2510 2511 2512 2513 2514 2515 2516

b. The key in the key information being distributed is used to perform the intended cryptographic operation on mutually known data (e.g., to encrypt plaintext data that is known by both the sender and the recipient). Both the key information and the cryptographically protected data are sent to the recipient. If the recipient can use the received key to successfully reverse or verify the cryptographic operation performed by the sender (e.g., by using the key to decrypt the received ciphertext data and successfully compare the resulting plaintext data with the mutually known plaintext data), the recipient has assurance that the key information has been received correctly. Otherwise, the key information is assumed to be corrupted.

2517 2518

2. Automated distribution via communication protocols (protection provided by the sending entity or by the communication protocol):

2519 2520 2521 2522 2523 2524

a. An approved cryptographic integrity mechanism (e.g., a MAC or digital signature) is used on the key information to be distributed, and the resulting code is provided to the recipient along with the key information for subsequent verification to obtain an assurance of integrity. A CRC is not approved for this purpose. The integrity mechanism may only be applied to the key information or to an entire message.

2525

-OR-

2526 2527 2528 2529 2530 2531 2532

b. The key in the key information is used by the sender to perform the intended cryptographic operation on data (e.g., compute a MAC on the data). Both the key information and the cryptographically protected data are sent to the recipient. If the recipient can successfully use the key to reverse or verify the cryptographic operation (e.g., verify the MAC on the received data using the received key), the recipient has assurance that the key information has been received correctly. Otherwise, the key information is assumed to be corrupted.

2533 2534 2535

The response to the detection of an integrity failure will vary, depending on the specific environment. Improper error handling can allow attacks (e.g., side-channel attacks). A security policy (see [SP 800-57p2]) should define the response to such an event. For example, 76

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

2536 2537 2538

Recommendation for Key Management Part 1 — General

if an error is detected in the received key information, and the receiver requires the key information to be entirely correct (e.g., the receiver cannot proceed when the key information is in error), then:

2539

•

The key information should not be used,

2540 2541

•

The recipient may request that the key information be resent (retransmissions should be limited to a predetermined maximum number of times), and

2542 2543

•

Information related to the incident should be saved in an audit log to later identify the source of the error.

2544

5.2.1.3. Confidentiality

2545 2546 2547

Confidentiality protection shall be provided for secret symmetric keys, asymmetric private keys, key shares, and other secret information (e.g., seeds or secret metadata) during transit using one or more of the following methods:

2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562

1. Manual method: a. The secret key information is encrypted (e.g., wrapped or encapsulated) using an approved technique that provides protection at a security strength that meets or exceeds the security strength required for the keying material (i.e., the security strength required for the protection of the data to be protected by the key). -ORb. A key is separated into key shares that are each generated at a security strength that meets or exceeds the security strength required by the keying material (i.e., the security strength required for the protection of the data to be protected by the key). Each key share is handled using split-knowledge procedures (see Sec. 7.1.5.2.1 and 7.1.5.2.2.1) so that no single individual can acquire access to all key shares. Any metadata that needs to be kept secret is encrypted. -OR-

2563 2564

c. Appropriate physical and procedural protection is provided (e.g., by using a trusted courier).

2565 2566 2567 2568 2569

2. Automated distribution via communication protocols: The secret key information is encrypted (e.g., wrapped or encapsulated) using an approved technique that provides protection at the security strength that meets or exceeds the security strength required of the keying material (i.e., the security strength required for the protection of the data to be protected by the key).

77

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2570

5.2.1.4. Association With Usage or Application

2571 2572 2573 2574

The association of keying material with its usage or application shall either be specifically identified during the distribution process (e.g., included in the transmitted metadata) or be implicitly defined by the use of the application. See Sec. 5.2.3 for a discussion of the metadata associated with keys.

2575

5.2.1.5. Association With Other Entities

2576 2577 2578 2579

The association of keying material with all appropriate entities (e.g., any entity that shares the keying material) shall either be specifically identified during the distribution process (e.g., using public-key certificates) or implicitly defined by the use of the application. See Sec. 5.2.3 for a discussion of the metadata associated with keys.

2580

5.2.1.6. Association With Other Related Key Information

2581 2582 2583 2584

Any association with other related key information (e.g., algorithm parameters, the encryption/decryption key, IVs) shall either be specifically identified during the distribution process or implicitly defined by the use of the application. See Sec. 5.2.3 for a discussion of the metadata associated with the other related key information.

2585

5.2.2. Protection Mechanisms for Key Information in Storage

2586 2587 2588

Key information may be stored in some device or on storage media. This may include copies of the key information that are also in transit or in use. Stored key information shall be protected in accordance with Sec. 5.1.

2589 2590 2591 2592 2593 2594

The key information may be stored so that it is immediately available to an application (e.g., on a local hard disk or a server). This would be typical for key information stored within a cryptographic module or in immediately accessible storage (e.g., on a local hard drive). The key information may also be stored in electronic form on removable media (e.g., a CD-ROM or flash drive) in a remotely accessible location or in hard copy form and placed in a safe. This would be typical for backup or archive storage.

2595 2596 2597 2598

Sections 5.2.2.1 through 5.2.2.3 address the availability, integrity, and confidentiality of key information. Sections 5.2.2.4 through 5.2.2.6 discuss the association of key information with its usage, application, other entities, and other related key information. Section 5.2.2.7 discusses storage media and mechanisms.

2599

5.2.2.1. Availability

2600 2601 2602 2603

Key information may need to be readily available for as long as data is protected by the key. A common method for providing this protection is to make one or more copies of the key information and store them in separate locations. During a key’s cryptoperiod, key information that requires long-term availability should be stored in both normal operational

78

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2604 2605 2606 2607

storage (see Sec. 7.2.1) and in backup storage (see Sec. 7.2.2.1). Key information that is retained after the end of a key’s cryptoperiod should be placed in archive storage (see Sec. 7.3.1). This recommendation does not preclude the use of the same storage media for both backup and archive storage.

2608 2609 2610 2611

Specifics on the long-term availability requirement for each key type are addressed for backup storage in Sec. 7.2.2.1 and for archive storage in Sec. 7.3.1. Some algorithms have strict requirements on key backup (e.g., the stateful hash-based signatures specified in [SP 800-208]).

2612 2613 2614 2615

The recovery of this key information to replace lost key information (e.g., from normal storage) or in performing cryptographic operations after the end of a key’s cryptoperiod is discussed in Sec. 7.2.2.2 (recovery during normal operations), Sec. 7.3.1 (recovery from archive storage), and Appendix B.

2616 2617 2618 2619 2620

Even though the primary focus of this section is to provide assurance of the availability of key information, there is at least one example in which denying the availability of this key information may be desired — namely, when sanitizing large volumes of key information that have been encrypted. In this case, cryptographic sanitization (i.e., destroying the key used to decrypt or unwrap the key information) is suggested (see [SP 800-88]).

2621

5.2.2.2. Integrity

2622 2623 2624 2625

Integrity protection is concerned with ensuring that the key information retrieved from storage is correct. While absolute protection against modification is not possible, reasonable measures can help prevent unauthorized modifications, detect any modifications that occur with a very high probability, and restore key information to its original content.

2626 2627

All key information requires integrity protection. Integrity protection shall be provided by physical mechanisms, cryptographic mechanisms, or both.

2628

Physical mechanisms include the use of:

2629 2630

•

A validated cryptographic module or operating system that limits access to the stored key information

2631

•

A computer system or media that is not connected to other systems

2632 2633

•

A physically secure environment with appropriate access controls that is outside of a computer system (e.g., in a safe with limited access)

2634

Cryptographic mechanisms include the use of:

2635 2636 2637

•

An approved cryptographic integrity mechanism (e.g., MAC or digital signature) that is computed on the key information before placing it in storage and is later used to verify the integrity of the stored key information and

2638

•

Performing the intended cryptographic operation.

2639 2640

If the retrieved key information is incorrect, the keying material may have been corrupted. In order to restore the key information when an error is detected, one or more copies of the 79

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2641 2642 2643

key information should be maintained in physically separate locations (i.e., in backup or archive storage; see Sec. 7.2.2.1 and 7.3.1). The integrity of each copy should be periodically checked.

2644

5.2.2.3. Confidentiality

2645 2646

One of the following mechanisms shall be used to provide confidentiality for key information that needs to remain secret while in storage:

2647 2648 2649 2650

•

2651 2652 2653 2654

-OR•

2655 2656 2657

Encryption (or key wrapping or encapsulation) using an approved algorithm in a [FIPS 140-3]-validated cryptographic module. The encryption shall use an approved technique that provides protection at a security strength that meets or exceeds the security strength required for the key information. Physical protection provided by a [FIPS 140-3]-validated cryptographic module at a security level that is consistent with the [FIPS 199] impact level associated with the data to be protected by the key (see [SP 800-152]). -OR-

•

Physical protection provided by secure storage with controlled access (e.g., a safe or protected area).

2658

5.2.2.4. Association With Usage or Application

2659 2660 2661 2662 2663 2664 2665

Keying material is used with a given cryptographic mechanism (e.g., to generate a digital signature or establish keys) or with a particular application. Protection shall be provided to ensure that the keying material is not used incorrectly (e.g., not only must the usage or application be associated with the keying material, but the integrity of this association must be maintained). This protection can be provided by separating the keying material from that of other mechanisms or applications or by using appropriate metadata associated with the keying material. Section 5.2.3 addresses the metadata associated with keys.

2666

5.2.2.5. Association With the Other Entities

2667 2668 2669 2670 2671 2672

Some key information needs to be correctly associated with another entity (e.g., the key source or an entity that owns or uses the key), and the integrity of this association shall be maintained. For example, a secret symmetric key used for the encryption of key information or the computation of a MAC needs to be associated with other entities that share the key. Public keys need to be correctly associated (e.g., cryptographically bound) with the owner of the key pair (e.g., using public-key certificates).

2673 2674 2675

The key information shall retain its association during storage by separating the key information by entity, application, or by using appropriate metadata for the key information when required. Section 5.2.3 addresses the use of the metadata.

80

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2676

5.2.2.6. Association With Other Related Key Information

2677 2678 2679

An association may need to be maintained between protected key information and the keying material that is used to protect that key information. In addition, keys may require association with other keying material (see Sec. 5.2.1.6).

2680 2681 2682 2683 2684 2685

Storing the key information together or providing some linkage or pointer between the information helps satisfy the association requirement. Often, the linkage between a key and the information it protects is accomplished by providing an identifier for a key, storing the identifier in the key’s metadata, and storing the key’s identifier with the data protected by the key. The association shall be maintained for as long as the protected data needs to be processed.

2686

5.2.2.7. Keying Material Storage Media and Mechanisms

2687 2688 2689 2690

Both cryptographic algorithms and the associated keying material may be stored in various places, including within the software or hardware running the algorithm, in a [FIPS 140-3]validated cryptographic module, in an HSM, in a Trusted Platform Module (TPM), in random access memory (RAM), on external digital media, and on paper.

2691

5.2.2.7.1 Cryptographic Modules

2692 2693 2694 2695 2696 2697

A cryptographic module is a set of hardware, software, and/or firmware that implements security functions and is contained within a cryptographic boundary. A module can be implemented in hardware, software, firmware, or a hybrid. The use of a [FIPS 140-3]validated cryptographic module is strongly recommended. FIPS 140 references the requirements specified in [ISO/IEC 19790]. Four implementation security levels are specified that increase in terms of the amount of protection provided:

2698 2699 2700 2701 2702

1. Security Level 1 provides the lowest level of security. Software or firmware modules may operate in a non-modifiable, limited, or modifiable operating environment, such as a general-purpose computing system. If a module is implemented in hardware, no specific physical security mechanisms are required beyond the basic requirement for production-grade components.

2703 2704 2705 2706

A Security Level 1 cryptographic module often relies on the physical security, network security, and administrative procedures of the system in which it resides. For example, the protection of keying material may need to be handled by the host system rather than the cryptographic module.

2707 2708 2709 2710

The physical environment in which the host system and cryptographic module reside may play a major role in protecting keying material (e.g., the accessibility to the system by unauthorized parties) as well as any security procedures for accessing the host system.

2711 2712

2. Security Level 2 adds a requirement for tamper evidence for the cryptographic module or the device in which it resides. Tamper-evident seals or pick-resistant locks

81

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2713 2714 2715 2716 2717 2718 2719

are used to protect against unauthorized physical access. Security Level 2 also requires role-based authentication in which a cryptographic module authenticates the authorization of an operator to assume a specific role and perform a corresponding set of services. Software cryptographic modules may be executed in a modifiable environment (e.g., general-purpose computer) that implements role-based access controls or, at a minimum, discretionary access control with a robust mechanism for defining groups and assigning restrictive permissions.

2720 2721 2722

In addition to Security Level 1 controls, a Security Level 2 cryptographic module relies on role-based operator authentication and tamper evidence to protect the keying material stored within the module or device.

2723 2724 2725

The security of the keying material also depends on the alertness and trustworthiness of the system operators, the physical security of the environment, and the security procedures for accessing the cryptographic module.

2726 2727 2728

3. Security Level 3 adds physical security protection that is intended to have a high probability of detecting and responding to attempts at physical access, unauthorized use, or modification of the cryptographic module. Security Level 3 also:

2729 2730 2731

o Requires identity-based authentication mechanisms to verify that an operator is authorized to assume a specific role and perform a corresponding set of services;

2732 2733 2734

o Requires the entry or output of security-related information (e.g., secret and private cryptographic keys) using encryption, a trusted channel, or splitknowledge procedures; and

2735 2736 2737

o Protects a cryptographic module against a security compromise due to environmental conditions or fluctuations outside of the module’s normal operating ranges for voltage and temperature.

2738 2739 2740 2741 2742

In addition to Security Level 2 controls, a Security Level 3 cryptographic hardware module relies on identity-based operator authentication, tamper response, and the detection of environmental fluctuations to protect the keying material stored within the module. Security Level 3 modules also protect the confidentiality and integrity of secret keying material that is entered into or output from the module.

2743 2744

Only authorized individuals have access to its content, and the confidentiality of its input and output is protected.

2745 2746 2747 2748

4. Security Level 4 adds requirements for responding to all unauthorized attempts at physical access. Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate zeroization of all plaintext security parameters.34 Security Level 4 introduces a multi-

34 The disclosure or modification of security-related information (e.g., secret and private cryptographic keys, authentication data) can compromise the security of a cryptographic module.

82

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

2749 2750

Recommendation for Key Management Part 1 — General

factor authentication requirement for operator authentication. At minimum, this requires two of the following three attributes:

2751

o Something known, such as a secret password

2752

o Something possessed, such as a physical key or token

2753

o A physical property, such as a biometric

2754 2755 2756 2757 2758

Security Level 4 includes special environmental protection features that are designed to detect voltage and temperature boundaries and zeroize sensitive information to provide a reasonable assurance that the module will not be affected when outside of the normal operating range in a manner that can compromise the security of the module.

2759 2760 2761 2762 2763

In addition to Security Level 3 controls, a Security Level 4 cryptographic hardware module relies on multi-factor authentication and enhanced physical mechanisms to protect the keying material stored within the module. A Security Level 4 cryptographic module is designed to destroy sensitive information (e.g., keying material) if an unauthorized attempt is made to access the module.

2764

5.2.2.7.2 Hardware Security Module (HSM)

2765 2766 2767 2768 2769 2770 2771

HSMs are special-purpose hardware devices that securely manage cryptographic keys and perform cryptographic operations using those keys. HSMs are built with tamper-evident and tamper-resistant cases and have detection mechanisms that zeroize sensitive data if a breach is attempted using sensors that detect voltage, temperature, and other environmental changes that might indicate tampering. HSMs securely manage a key’s life cycle, including its generation, storage, distribution, revocation, and destruction. Role-based access control is used to ensure that only authorized personnel can perform sensitive operations.

2772 2773 2774 2775 2776

HSMs are used within the public-key infrastructure (PKI) and digital signature systems, serve as secure digital wallets, facilitate transaction signing, are used for secure code signing, and provide security control over sensitive data in the cloud. Current HSMs that manage quantum-vulnerable cryptography will be or are being updated to support new quantumresistant algorithms.

2777 2778 2779 2780 2781

An HSM certified for [FIPS 140-3] cryptographic module compliance provides assurance at the appropriate security level that the HSM can effectively protect sensitive data and securely perform cryptographic functions securely. In addition, an HSM with a high Evaluation Assurance Level (EAL) certification under the Common Criteria standard has demonstrated the ability to meet additional stringent security requirements.

2782 2783 2784 2785 2786

To protect keying material appropriately, an HSM needs to support the range of cryptographic algorithms needed by the applications it supports. With the advent of quantum computing, support for approved quantum-resistant algorithms is recommended. Most of the approved algorithms require random number inputs, so an approved RBG should be included in the HSM. Methods for secure back up, archiving, and the recovery of keys should

83

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2787 2788

also be provided as well as detailed role-based access control policies and cryptographic agility to allow for easy changes to cryptographic components.

2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802

If using an HSM in conjunction with cloud services, an HSM that supports bring-your-own-key (BYOK), double key encryption (DKE), and hold-your-own-key (HYOK) integrations is recommended to provide the flexibility of leveraging cloud services while retaining the ability to both own and control encryption keys and/or reduce the risk of unauthorized data access or data loss. For each of these features, the keying material is generated and cryptographically protected in an HSM owned by a customer of the cloud service provider. When using the BYOK feature, the customer sends the keying material to the cloud for storage, and the keying material is cryptographically protected during its transit and in storage (e.g., by the customer’s key-wrapping key). When DKE is used, the customer sends the keying material to the cloud provider, and the keying material is encrypted a second time by the cloud provider before storing the doubly encrypted keying material. Both keys are required to decrypt and subsequently use the original plaintext keying material. When HYOK is used, the customer retains the cryptographically protected keying material but sends data protected by that keying material to the cloud for storage.

2803 2804

Although keying material is protected while remaining within the HSM, it must be cryptographically protected at an appropriate security strength when leaving the HSM.

2805

5.2.2.7.3 Trusted Platform Module (TPM)

2806 2807 2808 2809 2810 2811 2812 2813

A TPM was originally specified as a dedicated microprocessor that was designed to secure hardware using integrated cryptographic keys. A TPM provides a random number generator and the ability to generate cryptographic keys for a limited number of uses, including verification that the hardware and software within a device have not been changed, generating and encrypting cryptographic keys that can only be decrypted by the TPM, disk encryption to protect a computer’s storage devices, and digital rights management. These chips store the keys and perform cryptographic operations that depend on the keys. At no time does sensitive, plaintext keying material leave the TPM.

2814

The latest TPM version (TPM 2.0) specifies five types of TPM implementations:

2815 2816 2817 2818 2819

1. Discrete TPMs are dedicated chips that implement TPM functionality and provide some level of tamper resistance. Discrete TPMs can protect the confidentiality and integrity of the keying material within it. Depending on the quality of the tamperresistance feature, this protection may equate to a Security Level 2 or 3 cryptographic module (see Sec. 5.2.2.7.1).

2820 2821 2822 2823 2824

2. Integrated TPMs are only part of a chip and may not provide tamper resistance. Integrated TPMs within chips that can provide tamper detection can protect the confidentiality and integrity of the keying material within them. Otherwise, the protection, if available, would need to be provided by external means. This might equate to a Security Level 1 cryptographic module.

2825 2826

3. Firmware TPMs are firmware-based implementations that are run in a CPU’s trusted execution environment, which is a secure area of a computer’s main processor. 84

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2827 2828 2829

4. Virtual TPMs use hypervisors in isolated execution environments that are hidden from the software running inside virtual machines to secure their code from the software in the virtual machines.

2830 2831

5. Software TPMs are emulator TPMs but run with no more protection than a regular program gets within an operating system.

2832 2833 2834

TPM 2.0 includes several classical cryptographic algorithms: SHA-256, RSA, ECC with curve P256, HMAC, and AES-128. Additional algorithms are also defined but may be optional. Changing algorithms is accomplished by replacing the TPM implementation.

2835 2836

TPMs are commonly available on many computer systems. To utilize a TPM, a software library is used to communicate with the TPM.

2837 2838 2839

The amount of protection provided for keying material depends on the TPM being used. However, in all cases, keying material must be cryptographically protected at an appropriate security strength when leaving the TPM.

2840

5.2.2.7.4

2841 2842 2843 2844 2845 2846 2847

Random-access memory (RAM) is a form of computer memory that can be read and changed in any order and is typically used to store working data and machine code. Data in RAM can be read or written in almost the same amount of time, irrespective of the physical location of the data inside the memory. However, RAM is normally volatile memory (i.e., stored information is lost if power is removed). Non-volatile RAM has also been developed, and other types of non-volatile memories allow random access for read operations but either do not allow write operations or have other kinds of limitations.

2848 2849 2850

Keying material stored in RAM needs cryptographic protection applied by an appropriate cryptographic module. If the memory is volatile and the data is to be preserved beyond power loss, it needs to be backed up or archived (e.g., using external media; see Sec. 5.2.2.7.5).

2851

5.2.2.7.5 External Digital Media

2852

External media may be used to store keying material, such as:

2853 2854 2855 2856 2857 2858 2859 2860 2861

•

35

Random-Access Memory (RAM)

A flash drive (also known as a thumb drive) is a data storage device that includes flash memory 35 with an integrated USB interface. A typical USB drive is removable, rewritable, and small. Some allow up to 100,000 write/erase cycles, depending on the exact type of memory chip used, and are thought to physically last between 10 and 100 years under normal circumstances. Common uses of USB flash drives include storage, supplementary back-ups, and transferring computer files and other data. However, data loss from a bit leaking due to a prolonged lack of electrical power and the possibility of spontaneous controller failure due to poor manufacturing could make it unsuitable for long-term archiving of data.

Flash memory is an electronic non-volatile computer memory storage medium that can be electrically erased and reprogrammed.

85

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872

Keying material stored in flash memory needs cryptographic protection at an appropriate security strength that is applied by a cryptographic module. Flash drives should be stored in physical safes to ensure the continued availability of the data stored on them. Cryptographically protected long-term keying material and data should be backed up or archived using more reliable media. •

2880 2881 2882 2883 2884 2885

A hard drive is a data storage device that stores and retrieves digital data using magnetic storage. Data is accessed in a random-access manner, meaning that individual blocks of data can be stored and retrieved in any order. Hard drives have non-volatile storage (i.e., stored data is retained when the powered is turned off). The primary characteristics of a hard drive are its large capacity and performance (i.e., the time needed to access or write data). Keying material stored on a hard drive needs cryptographic protection applied by a cryptographic module at an appropriate security strength.

2873 2874 2875 2876 2877 2878 2879

•

A smart card is a plastic or metal card that contains either a microprocessor and a memory chip or only a memory chip with non-programmable logic. The microprocessor on the card can add, delete, and otherwise manipulate information on the card, while a memory-chip card (e.g., pre-paid phone cards) can only perform a predefined operation. There are currently three categories of smart cards: o

2886 2887 2888 2889 2890 2891

2897 2898 2899

Integrated circuit (IC) microprocessor cards (also known as “chip cards”) offer greater memory storage and data security than a traditional magnetic stripe card. Chip cards also can process data on the card. These cards are used for a variety of applications, especially those that have cryptography built in, which requires the manipulation of large numbers. Keying material stored on these cards requires cryptographic protection that is provided at an appropriate security strength by a cryptographic module either on or off the card.

o

2892 2893 2894 2895 2896

Recommendation for Key Management Part 1 — General

IC memory cards have no processor on the card with which to manipulate the data stored on it. They depend on a computer for processing and are suitable for performing fixed operations (e.g., key storage). Keying material stored on these cards requires cryptographic protection that is provided at an appropriate security strength by an off-card cryptographic module.

o

Optical memory cards can store data that cannot be changed or removed once written. Currently, these cards have no processor in them. Keying material stored on these cards requires cryptographic protection that is provided at an appropriate security strength by an off-card cryptographic module.

86

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

2900 2901 2902 2903 2904 2905 2906

Recommendation for Key Management Part 1 — General

Smart cards have a limited lifetime. Cryptographically protected long-term keying material and data must be backed up or archived on more reliable, long-term media. •

Keying material may be printed on or punched into paper or other physical media. The keying material could be encrypted, split into multiple key components, or handled using dual-control procedures. Printed or punched keying material can be in plaintext form, although this is not recommended. When not in use, printed or punched keying material should be stored in a physical safe. The keying material should be backed up or archived for as long as it is needed to remove or verify any cryptographic protection that was applied to the information.

2907 2908 2909

5.2.3. Metadata for Keys

2910 2911 2912 2913 2914 2915 2916 2917

Metadata is used to provide information about a key, including its attributes and intended use. Different applications may require different metadata elements for the same key type, and different metadata elements may be required for different key types. Implementers are responsible for selecting suitable metadata elements for keys. When metadata is used, the metadata should accompany a key (i.e., the metadata is typically stored or transmitted with a key). However, depending on an application and implementation, some metadata may be explicitly known (e.g., all information has the same sensitivity, or all keys are used by a single application).

2918

Some examples of metadata elements include:

2919

•

The seed used to (re)generate a key or key pair (if appropriate)

2920

•

A key identifier

2921

•

The algorithm to be used with the key

2922 2923

•

Information that identifies associated keys (e.g., the association between a public and private key)

2924

•

The identity of the key’s owner or the identifiers of the sharing entities

2925 2926

•

If the owner is a non-human entity, the identity of sponsors or representatives for the owner

2927

•

If the owner is a device or process, the location of the device or process

2928 2929

•

The key’s cryptoperiod (e.g., the start and end dates for using the key to protect or process information)

2930

•

The key type (e.g., signing private key, encryption key or decapsulation key)

2931

•

The source of the keying material (i.e., the entity that provided the key)

2932

•

The application with which the key is to be used (e.g., purchasing or email)

2933

•

The sensitivity of the information protected by the key

2934

•

A counter, which is used to detect the playback of a previously transmitted key 87

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2935 2936

•

The current key state (i.e., pre-activation, active, suspended, compromised, or destroyed)

2937 2938

•

The key’s status and/or history (i.e., distributed, suspended, or revoked with the revocation reason)

2939 2940

•

The identity of the key-wrapping key or decapsulation key used to wrap/decapsulate the key and the algorithm used for wrapping or decapsulation

2941 2942

•

The integrity-protection mechanism used (e.g., the key and algorithm used to provide cryptographic protection for the key information and the protection code)

2943 2944

•

Other information (e.g., the length of the key, any protection requirements, who has access rights to the key, or additional conditions for use)

2945 2946

[SP 800-152] provides additional information about the use of metadata, including guidelines for protecting its integrity and association with the related key.

2947

88

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2948

6. Key States and Transitions

2949 2950

A key may pass through several states between its generation and destruction. Figure 3 depicts an example of the key states that a key could assume and the transitions among them.

2951 2952

Fig. 3. Key state and transition example

2953 2954 2955 2956 2957 2958 2959 2960

A key may be used differently, depending on its state in the key’s life cycle. Key states are defined from a system point of view as opposed to the point of view of a single cryptographic module. The following sections discuss the states that an operational or backed-up key may assume as well as transitions to other states, as shown in Fig. 3. Additional states may be applicable for some systems (e.g., deactivated and destroyed compromised states, which were depicted in the example provided in previous versions of this recommendation), and some of the identified states may not be needed for a system (e.g., a decision could be made that the suspended state will not be used).

2961 2962 2963

Transitioning between states shall be recorded. Suitable places for such recordings are audit logs and the key’s metadata (see Sec. 5.2.3). [SP 800-152] discusses the logging of these events, including the minimum information that shall be recorded for each event.

89

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

2964

The following sections discuss the example states and transitions provided in Fig. 3.

2965

6.1. Pre-Activation State

2966 2967

The key has been generated but has not been authorized for use. Keys to be inventoried (e.g., long-term keys) shall be inventoried upon generation (see Sec. 8.2).

2968 2969 2970 2971 2972

In this state, the key may only be used to perform proof-of-possession (Sec. 7.1.5.1.1.2) or key confirmation (see [SP 800-175B]). Otherwise, a key shall not be used to apply cryptographic protection to information (e.g., encrypt or sign information to be transmitted or stored) or to process cryptographically protected information (e.g., decrypt ciphertext or verify a digital signature) while in this state.

2973 2974

•

State Transition 1 (enter the pre-activation state): A key enters the pre-activation state immediately upon generation. Information about the generation of the key shall be recorded.

2975 2976 2977 2978 2979

•

State Transition 2 (pre-activation state to the destroyed state): If a key is in the preactivation state and will not be needed in the future, the key shall transition directly from the pre-activation state to the destroyed state (Sec. 6.5). In the case of asymmetric keys, both keys of the key pair shall transition to the destroyed state.

2980 2981 2982 2983 2984

•

State Transition 3 (pre-activation state to the compromised state): When a key is in the pre-activation state, and the integrity of the key or the confidentiality of a key requiring confidentiality protection becomes suspect, then the key shall transition from the pre-activation state to the compromised state (Sec. 6.4). In the case of asymmetric keys, both keys of the key pair shall transition to the compromised state. If the key is known by multiple entities, a revocation notice shall be generated.

2985 2986 2987 2988 2989 2990

•

State Transition 4 (pre-activation state to active state): Keys shall transition from the pre-activation state to the active state (Sec. 6.2) when the key becomes available for operational use. This transition may occur upon reaching an activation date or because of an external event. If keys are generated for immediate use, the transition occurs immediately after entering the pre-activation state.

2991 2992 2993

For asymmetric keys associated with a certificate, both keys of the key pair become active upon the notBefore date (if used) in the first certificate issued for the public key of the key pair.

2994 2995

This transition marks the beginning of the cryptoperiod of a symmetric key or both keys of an asymmetric key pair (see Sec. 4.3).

2996

6.2. Active State

2997 2998 2999

In the active state, the key may be used to cryptographically protect information (e.g., encrypt plaintext or generate a digital signature), cryptographically process previously protected information (e.g., decrypt ciphertext or verify a digital signature), or both. When a key is 90

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3000 3001 3002 3003 3004 3005 3006 3007

active, it may be designated for protection only, processing only, or both protection and processing, depending on its type. For example, asymmetric private signature keys, public key-transport keys, and public static/ephemeral encapsulation keys are implicitly designated to only apply protection. Public signature-verification keys, private key-transport keys, and private static/ephemeral decapsulation keys are designated for processing only. A symmetric data-encryption key may be used to encrypt data during its originator-usage period and decrypt the encrypted data during its recipient-usage period (see Sec. 4.3.5). Keys that are disallowed shall be used for processing only (see [SP 800-131A]).

3008

The use of each key in the active state should be recorded (see [SP 800-152]).

3009 3010 3011 3012

•

State Transition 5 (active state to the destroyed state): Keys transition from the active state to the destroyed state if they are no longer needed or if the end of their cryptoperiod is reached, as shown in Table 9. Table 9. Transition from the active state to the destroyed state Key Type

Transition 5: Active to Destroyed State Digital Signatures

1. Private signature key

At the end of the cryptoperiod (e.g., when the notAfter date is reached on the last certificate issued for the public key)

2. Public signatureverification key

When no longer needed Authentication

3. Symmetric authentication key

At the end of the recipient-usage period or when no longer needed

4. Private authentication key

At the end of the cryptoperiod (e.g., when the notAfter date is reached on the last certificate issued for the public key)

5. Public authentication key

When no longer needed Random Bit Generation

6. Symmetric RBG keys

When replaced by a new key or when the RBG will no longer be used Key Derivation

7. Symmetric key derivation key

At the end of the originator-usage period or when no longer needed Key Establishment (automated)

8. Symmetric keywrapping/unwrapping key

At the end of the recipient-usage period or when no longer needed

9. Public key transport key

At the end of the cryptoperiod (e.g., when the notAfter date is reached on the last certificate issued for the public key)

10. Private key transport key

When no longer needed

11. Symmetric key-agreement key

At the end of the recipient-usage period or when no longer needed

91

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025 Key Type

Recommendation for Key Management Part 1 — General Transition 5: Active to Destroyed State

12. Public static keyagreement key

At the end of the cryptoperiod (e.g., when the notAfter date is reached on the last certificate issued for the public key)

13. Private static keyagreement key

Should usually transition at the end of the public key’s cryptoperiod (see [SP 800-131A] for exceptions)

14. Public ephemeral keyagreement key 15. Private ephemeral keyagreement key

Immediately after use

16. Public static encapsulation key

At the end of the cryptoperiod (e.g., when the notAfter date is reached on the last certificate issued for the public key)

17. Private static decapsulation key

When no longer needed

18. Public ephemeral encapsulation key

Immediately after use

19. Private ephemeral decapsulation key

Data Encryption/Decryption 20. Symmetric data encryption/decryption key of data in transit 21. Symmetric data encryption/decryption key of data at rest

At the end of the recipient-usage period or when no longer needed

Key Storage (for operational, backup, and archive storage) 22. Symmetric keywrapping/unwrapping key

At the end of the recipient-usage period or when no longer needed

23. Public key-wrapping key

At the end of its cryptoperiod

24.Private key-unwrapping key

When no longer needed

25. Public encapsulation key

At the end of its cryptoperiod

26.Private decapsulation key

When no longer needed Authorization

27. Symmetric authorization key 28. Private authorization key 29. Public authorization key

3013 3014

•

At the end of the originator-usage period At the end of its cryptoperiod (e.g., when the notAfter date is reached on the last certificate issued for the corresponding public key)

State Transition 6 (active state to the compromised state): A symmetric key or asymmetric key pair shall transition from the active state to the compromised state 92

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3015 3016 3017 3018 3019 3020 3021 3022

(see Sec. 6.4) when the confidentiality or integrity of the symmetric key or the confidentiality of an asymmetric private key becomes suspect. In this case, the key or key pair shall be revoked. In the case of asymmetric key pairs, the compromise pertains explicitly to the private key of the key pair, but both keys shall transition to the compromised state at the same time. For example, when a private signature key, private key-transport key, or private static/ephemeral decapsulation key is either compromised or suspected of being compromised, the corresponding public key also needs to transition to the compromised state.

3023

If the key is known by multiple entities, a revocation notice shall be generated.

3024 3025 3026 3027 3028 3029 3030 3031

•

State Transition 7 (active state to the suspended state): When a suspended state is used by an application (see Sec. 6.3) and the key or key pair is not to be used for a period of time (i.e., the period of suspension), a symmetric key or both keys of a key pair shall transition from the active state to the suspended state. For example, a private signature key may be suspended because the entity associated with the key is on a leave of absence or there is suspicion that the key may have been compromised. In the latter case, the suspension will allow for an investigation of the key’s status before initiating costly revocation and replacement processes.

3032 3033

Symmetric RBG keys shall transition to the compromised state and be replaced rather than remaining in the suspended state.

3034 3035

If the key or key pair is known by multiple entities, a notification indicating the suspension and reason shall be generated.

3036

6.3. Suspended State

3037 3038 3039 3040 3041 3042 3043

The use of a non-ephemeral key or key pair may be suspended for several reasons.36 One reason might be a possible key compromise, in which case the suspension might be issued to allow time to investigate the situation. Another reason might be that the entity that owns a digital signature key pair is not available (e.g., the entity is on an extended leave of absence). Signatures purportedly signed during the suspension time would be invalid. Depending on the reason for the suspension, a suspended key or key pair may be restored to an active or destroyed state or may transition to the compromised state.

3044 3045 3046 3047 3048 3049 3050 3051 3052

A suspended key shall not be used to apply cryptographic protection (e.g., encrypt plaintext or generate a digital signature). However, depending on the reason for the suspension, a suspended key could be used to process information for which cryptographic protection was known to be applied before the suspension period. This includes the use of a publicverification key to verify a digital signature, a symmetric data-encryption key to decrypt encrypted information, a symmetric key-wrapping key to unwrap keying material, and a private decapsulation key to decapsulate an encapsulated key. If the reason for the suspension is a suspected compromise, it may not be prudent to verify any signatures using the public key until and unless the key pair is subsequently reactivated (i.e., the key was not 36 In the case of asymmetric key pairs, both the public and private keys shall be suspended at the same time.

93

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3053 3054 3055

compromised), even if the risk is acceptable. However, if the reason is that the owner is on a leave of absence, verifying signatures known to be generated before the beginning of the suspension period may be warranted.

3056 3057

Information for which protection is known to have been applied during the suspension period shall not be processed.

3058 3059 3060 3061 3062

•

State Transition 8 (suspended state to the active state): A key or key pair in the suspended state shall transition to the active state when the reason for the suspension no longer exists and the end of the cryptoperiod has not been reached. In the case of symmetric keys, the transition needs to be made before the end of the key’s recipient-usage period.

3063 3064 3065 3066 3067

•

State Transition 9 (suspended state to the destroyed state): Keys may transition from the suspended state to the destroyed state (Sec. 6.5) if no compromise has been determined and the key is either no longer needed or the end of the cryptoperiod has been reached. See Table 9 in Sec. 6.2 for transitions to the destroyed state for each key type.

3068 3069 3070 3071

•

State Transition 10 (suspended state to the compromised state): A key or key pair in the suspended state shall transition to the compromised state when the integrity of the key or the confidentiality of a key requiring confidentiality protection becomes suspect or is confirmed. In this case, the key or key pair shall be revoked.

3072 3073

In the case of asymmetric key pairs, both the public and private keys shall transition at the same time.

3074

If the key is known by multiple entities, a revocation notice shall be generated.

3075

6.4. Compromised State

3076 3077 3078 3079 3080 3081 3082 3083 3084

Generally, keys are compromised when they are provided to or determined by an unauthorized entity. A compromised key 37 shall not be used to apply cryptographic protection to information. However, a compromised symmetric key or a public key that corresponds to a compromised private key of a key pair may sometimes be used to process cryptographically protected information. For example, a signature may be verified to determine the integrity of signed data if its signature has been physically protected since a time before the compromise occurred or a reliable timestamp has been included in the signed data. This processing shall be done only under highly controlled conditions and when the users of the information are fully aware of the possible consequences.

3085 3086

•

State Transition 11: The following keys shall transition immediately to the destroyed state when a compromise is suspected:

3087

1.

Private signature key

3088

4.

Private authentication key

37 Keys retrieved from an archive may be in the compromised state.

94

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3089

6.

Symmetric RBG key

3090

7.

Symmetric key-derivation

3091

9.

Public key-transport key

3092

12-15. Private and public key-agreement keys (both static and ephemeral)

3093

16, 18. Public encapsulation keys for key storage (both static and ephemeral)

3094

22.

Symmetric key-wrapping/unwrapping key

3095

23.

Public key wrapping key for key storage

3096

25.

Public encapsulation key for key storage

3097

27 .

Symmetric authorization key

3098

28, 29. Public and private authorization keys

3099 3100 3101

The following keys may continue to be used to process protected information when needed unless accepting the processed information carries too much risk, at which time they shall transition to the destroyed state:

3102 3103

2.

Public signature-verification key (to verify signatures generated using the corresponding private signature key)

3104

3.

Symmetric authentication key (to verify a MAC generated using this key)

3105 3106

5.

Public authentication key (to verify signatures generated using the corresponding private authentication key)

3107 3108

8.

Symmetric key-wrapping/unwrapping key (to unwrap keys that were wrapped using this symmetric key-wrapping key)

3109 3110

10.

Private key-transport key (to decrypt keys that were encrypted using the corresponding public key-transport key)

3111

11.

Symmetric key-agreement key (to determine an agreed-upon key)

3112 3113

17, 19. Private decapsulation key (to decapsulate a key that was encapsulated for key establishment, both static and ephemeral)

3114 3115

20, 21. Symmetric data encryption/decryption key (to decrypt data that was encrypted using this key)

3116

24.

Private key unwrapping key for storage (to unwrap stored keys)

3117

26.

Private decapsulation key (to decapsulate stored keys)

3118

Keys should transition to the destroyed state when no longer needed.

3119

6.5. Destroyed State

3120 3121

Transitioning to this state results in the destruction of a key. Even though the key no longer exists when in this state, certain metadata (e.g., the owner’s identity, key state transition

95

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3122 3123

history, key name, type, and/or cryptoperiod) may be retained for audit purposes (see Sec. 7.4).

3124 3125

A compromise of a key could be determined after the key has already been destroyed. In this case, the event shall be recorded (see [SP 800-152]).

3126

96

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3127

7. Key-Management Phases and Functions

3128 3129 3130 3131

The cryptographic key-management lifecycle can be divided into four phases. During each phase, the keys are in certain specific key states as discussed in Section 6. In addition, within each phase, certain key-management functions are typically performed. These functions are necessary for the management of the keys and their associated metadata.

3132 3133 3134 3135 3136 3137

Key-management information is called metadata and may include the identity of a person or system associated with that key or the types of information that person is authorized to access. Metadata is used by applications to select the appropriate cryptographic keys for a particular service. While the metadata does not appear in cryptographic algorithms, it is crucial to the implementation of applications and application protocols. See Sec. 5.2.3 for additional discussion about metadata.

3138 3139 3140

During the phases of the cryptographic key-management life cycle, the keys are in specific key states (see Sec. 6), and certain key-management functions are typically performed. These functions are necessary for the management of the keys and their associated metadata.

3141

The four phases of key management are:

3142 3143 3144

1. Pre-operational phase: The keying material is not yet available for normal cryptographic operations. Keys may not yet be generated or are in the pre-activation state. System or enterprise attributes are established during this phase as well.

3145 3146 3147 3148

2. Operational phase: The keying material is available and in normal use. Keys are in the active or suspended state. Keys in the active state may be designated as protect only, process only, or allowed for both protection and processing. Keys in the suspended state can sometimes be used for processing only (see Sec. 6.3).

3149 3150 3151 3152

3. Post-operational phase: The keying material is no longer in normal use, but access to the keying material is possible, and the keying material may be used for processing protected information. Keys are in the compromised state or have been temporarily reactivated from an archive (see Sec. 7.3.1).

3153 3154 3155

4. Destroyed phase: Keys are in the destroyed state and no longer available. Records of their existence may or may not have been destroyed, but the key’s metadata (e.g., key name, type, cryptoperiod, usage period) may be retained (see Sec. 7.4).

3156

A flow diagram for the key-management phases is presented in Fig. 4.

97

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

1 2

Pre-Operational Phase

3

4 Operational Phase

5

6 7

3157 3158 3159 3160

Post-Operational Phase

Destroyed Phase Fig. 4. Key-management phases

There are seven phase transitions, and a key shall not be able to transfer back to any previous phase:

3161 3162

1. Phase Transition 1: A key is in the pre-operational phase upon generation (preactivation state).

3163 3164

2. Phase Transition 2: If keys are produced but never used, they may be destroyed by transitioning from the pre-operational phase directly to the destroyed phase.

3165 3166

3. Phase Transition 3: When a key in the pre-operational phase is compromised, it transitions to the post-operational phase (compromised state).

3167 3168 3169 3170

4. Phase Transition 4: After the required metadata has been established, keying material has been generated, and the metadata is associated with the key during the preoperational phase, the key is ready to be used by applications and transitions to the operational phase at the appropriate time.

3171 3172

5. Phase Transition 5: When a key in the operational phase is compromised, it transitions to the post-operational phase (compromised state).

98

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3173 3174 3175

6. Phase Transition 6: When keys are no longer required for normal use (e.g., the end of the cryptoperiod has been reached and the key is no longer “active”) but access to those keys needs to be maintained, the key transitions to the post-operational phase.

3176 3177 3178 3179

7. Phase Transition 7: Some applications will require that access be preserved for a period of time, and then the keying material may be destroyed. When it is clear that a key in the post-operational phase is no longer needed, it may transition to the destroyed phase.

3180

The combination of key states and key phases is illustrated in Fig. 5.

3181 3182

Fig. 5. Key-management states and phases

3183 3184 3185 3186 3187 3188

The following subsections discuss the functions that are performed in each phase of key management. References to “systems” refer to systems that handle keys, whether the system is a client using some protocol or an entire key-management system. A key-management system may perform many of the functions but not have all identified functions, since some functions may not be appropriate. In some cases, one or more functions may be combined, or the functions may be performed in a different order. For example, a system may omit the 99

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3189 3190 3191

functions of the post-operational phase if keys are immediately destroyed when they are no longer used to apply cryptographic protection or are compromised. In this case, keys would move from the operational phase directly to the destroyed phase.

3192

7.1. Pre-Operational Phase

3193 3194

During the pre-operational phase of key management, keying material is not yet available for normal cryptographic operations.

3195

7.1.1. Entity Registration Function

3196 3197 3198 3199 3200 3201 3202 3203

During registration into a key-management system, an entity interacts with a registration authority to become an authorized member of a security domain. In this phase, an entity identifier may be established to identify the member during future transactions. In particular, security infrastructures may associate the identification information with the entity’s keys (see Sec. 7.1.5 and 7.1.6). The entity may supply various information, such as an email address and the entity’s role, and authorization information may be established by the system administrator. As with identity information, the infrastructure may associate this information with the entity’s keys to support secure application-level security services.

3204 3205 3206 3207 3208 3209 3210

Since applications will depend on the identity established during this process, it is crucial that appropriate procedures for the validation of identity (i.e., identity proofing) be established and used. Identity proofing is often performed by an organization (e.g., by the organization’s security office) but may also be performed by a registration authority for the keymanagement system. The strength (or weakness) of a security infrastructure will often depend on the identification process. [FIPS 201-3] and [SP 800-63] address requirements for establishing identity.

3211 3212 3213 3214 3215 3216

Entity and key registration (see Sec. 7.1.6) may be performed separately or at the same time. If performed separately, the entity registration process will generally establish a secret value (e.g., a password or PIN, MAC key) that may be used to authenticate the entity’s identity during the key-registration step. If entity and key registration are performed at the same time, the entity establishes an identity and performs key registration in the same process, so the secret value is not required.

3217

7.1.2. System Initialization Function

3218 3219 3220 3221

System initialization involves setting up or configuring a system for secure operation. For systems that handle keys, this may include algorithm preferences, the identification of trusted parties, and the definition of algorithm parameter policies and any trusted parameters (e.g., recognized certificate policies).

100

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3222

7.1.3. Initialization Function

3223 3224 3225 3226 3227

Initialization consists of an entity that initializes its cryptographic application (e.g., installing and initializing software or hardware). This involves the use or installation of any initial keying material that may be obtained during entity registration (see Sec. 7.1.4). Examples include the installation of a key at a CA, trust parameters, policies, trusted parties, and algorithm preferences.

3228

7.1.4. Keying-Material Installation Function

3229 3230 3231 3232 3233 3234 3235 3236

The security of keying-material installation is crucial to the security of a system, whether the keying material is generated within the system (e.g., in the system’s cryptographic module) or generated within another system and subsequently installed in the target system. For this function, keying material is installed for operational use within an entity’s software, hardware, system, application, cryptographic module, or device using a variety of techniques. Keying material is installed during initial setup when new keying material is added to the existing keying material and when the existing keying material is replaced (e.g., via re-keying or key derivation; see Sec. 7.2.3 and 7.2.4).

3237 3238 3239 3240 3241 3242

The process for the initial installation of keying material (e.g., by manual entry, using an electronic key loader, or a vendor during manufacture) shall include the protection of the keying material during entry into a software, hardware, system, application, device, or cryptographic module and include any additional procedures that may be required. The process should account for the requirements of [FIPS 140-3] and its differing requirements for the different levels of protection.

3243 3244 3245

Many manufacturers provide applications or systems with keying material that is used to test that the newly installed application/system is functioning properly. This test keying material shall not be used operationally.

3246

7.1.5. Key-Establishment Function

3247 3248 3249 3250 3251 3252 3253 3254

Key establishment involves the generation and distribution or the agreement of keying material for communication between entities. All keys shall be generated within a [FIPS 1403]-validated cryptographic module or obtained from another source that is approved to protect national security information. Long-term keys shall be inventoried (see Sec. 8.2). During the key-establishment process, some of the keying material may be in transit (i.e., the keying material is being distributed manually or using automated protocols). Other keying material may be retained locally rather than distributed. In either case, the keying material shall be protected in accordance with Sec. 5.

3255 3256 3257 3258 3259

An entity may be an individual (human), organization, device, or process. When keying material is generated by an entity for its own use, one or more of the appropriate protection mechanisms for stored information in Sec. 5.2.2 shall be used. The “owner” of a key is an entity that is authorized to use the key. When the owner is not a human (i.e., the owner is an organization, device, or process), the owner is often assisted by an authorized human 101

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3260 3261

representative or sponsor to obtain and manage keying material (e.g., to obtain and install keys and certificates).

3262 3263 3264 3265 3266 3267 3268

Keying material that is distributed between entities or among an entity and its sub-entities (e.g., various individuals, devices, or processes within an organization) shall be protected during distribution using one or more of the appropriate protection mechanisms specified in Sec. 5.2.1. Any keying material that is not distributed (e.g., the private key of a key pair or one’s own copy of a symmetric key) or keying material that is received and subsequently stored shall be protected using one or more of the appropriate protection mechanisms specified in Sec. 5.2.2.

3269 3270

Sections 7.1.5.1 and 7.1.5.2 discuss the generation and distribution of asymmetric and symmetric keys, respectively. [SP 800-133] discusses the generation of keying material.

3271

7.1.5.1. Generation and Distribution of Asymmetric Key Pairs

3272 3273

Key pairs shall be generated in accordance with the mathematical specifications of the appropriate approved FIPS or NIST SP.

3274 3275 3276 3277

A static key pair shall be generated by 1) the entity that owns the key pair (i.e., the entity that uses the private key in the cryptographic computations) or 2) a trusted facility that distributes the key pair in accordance with Sec. 7.1.5.1.3, or 3) the owner and facility in a cooperative process.

3278 3279 3280 3281 3282 3283 3284 3285

In the case of a digital signature key pair (i.e., a public signature-verification key and its associated private signature key), the intended owner of the key pair should generate the keying material rather than any other entity generating the keying material for that owner. This will facilitate support for non-repudiation. When generated by the entity that owns the key pair, the private signature key shall not be distributed to other entities. However, when the owner is an organization, it is acceptable to distribute the keying material to the organization’s sub-entities (e.g., employees or devices). In this case, the organization is the true owner, and the sub-entities represent the owner.

3286 3287 3288

Ephemeral keys are often used for key establishment instead of or in addition to the use of static keys (see [SP 800-56A] and [SP 800-227]). Ephemeral key pairs are generated for each new key-establishment transaction (e.g., unique to each message or session) by the owner.

3289

The generated key pairs shall be protected in accordance with Sec. 5.1.1.

3290

7.1.5.1.1.

3291 3292 3293 3294 3295

Static public keys are relatively long-lived and typically used for several executions of an algorithm. Ephemeral public keys are used only once. The distribution of the static or ephemeral public key should provide assurance to the receiver of the public key that the true owner of the key is known (i.e., that the claimed owner is the actual owner). This requirement may be disregarded if anonymity is acceptable. However, the strength of the overall

Distribution of Public Keys

102

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3296 3297

architecture and trust in the validity of the protected data largely depends on assurance of the public-key owner’s identity.

3298

In addition, the distribution of the public key shall provide assurance to the receiver that:

3299 3300

1. The purpose/usage of the key is known (e.g., for RSA digital signatures, elliptic-curve key agreement, key encapsulation);

3301

2. Any parameters associated with the public key are known;

3302 3303

3. The public key is valid (e.g., the public key satisfies the required arithmetical properties); and

3304

4. The owner actually possesses the corresponding private key.

3305

7.1.5.1.1.1.

Distribution of a Trust Anchor’s Public Key in a PKI

3306 3307 3308 3309 3310 3311 3312 3313 3314 3315

The public key of a trusted certification authority (CA) is the foundation for all PKI-based security services; the trusted CA is considered to be a trust anchor.38 The trust anchor’s public key is not a secret, but the authenticity of that public key is the crucial assumption for a PKI. Trust anchor public keys may be obtained through many different mechanisms and provide different levels of assurance. The types of mechanisms may depend on the role of an entity in the infrastructure. An entity that only ever acts as a “relying party” (i.e., an entity that may not have keys registered with the infrastructure) may use different mechanisms than an entity that possesses keys registered by the infrastructure. Trust-anchor public keys are frequently distributed as root-CA certificates, which are “self-signed” X.509 certificates that are signed by the private key corresponding to the public key in the certificate.

3316 3317 3318 3319 3320 3321 3322

Trust-anchor certificates are often embedded in and distributed with an application. For example, the installation of a new web browser typically includes the installation or replacement of an entity’s list of trust-anchor certificates. Operating systems are usually shipped with trust-anchor certificates for a variety of reasons, including the validation of other certificates. The entity relies on the authenticity of the software distribution mechanism to ensure that only valid trust-anchor certificates are installed during installation or replacement.

3323 3324 3325 3326 3327

Other applications sometimes install trust-anchor certificates in web browsers for several purposes, including the validation of the TLS certificates presented in TLS protocols. Entities that visit a “secure” website that has a certificate that was not issued by a trust anchor CA may be given an opportunity to accept that certificate, either for a single session or permanently.

3328 3329 3330 3331

Roaming users should be aware that they are implicitly trusting all software on the host systems that they use. They should have concerns about trust-anchor certificates used by web browsers when they use systems in kiosks, libraries, internet cafes, or hotels, as well 38 While this document refers to a trusted CA as the “trust anchor” and its certificate as the “trust-anchor certificate,” many other documents use the term “trust anchor” to refer to both the trusted CA and the CA’s certificate.

103

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3332 3333 3334 3335 3336

as systems provided by conference organizers to access “secure websites.” The user has had no control over the trust-anchor certificates installed in the host system, and therefore, the user is relying on the host system administrators to have made good, sensible decisions about which trust-anchor certificates are allowed.

3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348

Relying parties should be cautious about accepting certificates from unknown CAs so that they do not inadvertently add new permanent trust-anchor certificates that are not trustworthy. Relying parties are not participants in trust-anchor certificate selection when the trust-anchor certificates are pre-installed prior to software distribution and may have had no part in decisions about which trustanchor certificates are installed thereafter. Users should be aware that they are trusting the software distribution mechanism to not have resulted in the installation of malicious code. Extending this trust to cover trust-anchor certificates for a given application may be reasonable and allows the relying party to obtain trust-anchor certificates without any additional procedures.

3349 3350 3351 3352 3353

An entity (or an entity’s representative) interacts securely with the infrastructure to register its keys (e.g., to obtain certificates), and these interactions may be extended to provide trustanchor information in the form of a trust-anchor certificate. This allows the establishment of trust-anchor certificates with approximately the same assurance that the infrastructure has in the entity’s keys. In the case of a PKI:

3354 3355 3356 3357 3358 3359 3360 3361 3362 3363

1. The initial distribution of a trust-anchor certificate should be performed in conjunction with the presentation of a requesting entity’s public key to a registration authority (RA) or CA during the certificate-request process. In general, the trust anchor’s public key, associated parameters, key use, and assurance of possession are conveyed as a self-signed X.509 public-key certificate (also called a root-CA certificate). In this case, the certificate has been digitally signed by the private key that corresponds to the public key within the certificate. While the parameters and assurance of possession may be conveyed in the self-signed certificate, the identity associated with the trust-anchor certificate and other information cannot be verified from the self-signed certificate itself (see item 2 below).

3364 3365 3366 3367 3368 3369 3370

2. The trusted process used to convey a requesting entity’s public key and assurances to the RA or CA shall also be used to protect the trust-anchor’s certificate that is conveyed to the requesting entity. If the requesting entity (or the entity’s representative) appears in person, the trust-anchor’s certificate may be provided at that time. If a secret value has been established during entity registration (see Sec. 7.1.1), the trust-anchor’s certificate may be supplied along with the requesting entity’s certificate.

104

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3371

7.1.5.1.1.2.

Submission to a Registration Authority or Certification Authority

3372 3373 3374 3375

Public keys may be provided to a CA or RA for subsequent certification by a CA. During this process, the RA or CA shall obtain the assurances listed in Sec. 7.1.5.1.1 and the owner’s identity from the entity submitting the key (i.e., the owner of the key or an authorized representative).

3376 3377 3378 3379 3380

In general, the owner of the key is identified in terms of an identifier established during entity registration (see Sec. 7.1.1). During entity registration, the appropriate uses for the key are identified along with any required parameters. If anonymous ownership of the public key is acceptable, the submitter or the registration authority determines a pseudonym to be used as the identifier. The identifier shall be unique for the naming authority. 39

3381 3382 3383 3384

Proof of possession (POP) is a mechanism that is commonly used by a CA to obtain assurance of private-key possession during key registration. In this case, the proof shall be provided by the reputed owner of the key pair. Without assurance of possession, it would be possible for the CA to bind the public key to the wrong entity.

3385 3386

The (claimed) owner should provide POP by performing operations with the private key that satisfy the indicated key use. For example:

3387 3388 3389

•

If a key pair is intended for ML-DSA digital signature generation, the CA may provide information to be signed using the owner’s private key. If the CA can correctly verify the signature using the corresponding public key, then the owner has established POP.

3390 3391 3392 3393

•

If a key pair is intended for key transport (as specified in [SP 800-56B]) or key encapsulation (as specified in [SP 800-227]), the CA may provide ciphertext using the owner’s public key. If the owner can correctly decrypt the ciphertext, then the owner has established POP.

3394 3395 3396 3397 3398 3399 3400

•

When a key pair is intended to support key establishment (i.e., either key agreement or key transport), and the key pair was generated as specified in [FIPS 186-5] 40 (see [SP 800-56A] and [SP 800-56B]), POP may be afforded by using the private key to digitally sign the certificate request, although this is not the preferred method. The private key-establishment key (i.e., the private key-agreement or private keytransport key) shall not be used to perform signature operations after certificate issuance.

3401 3402 3403 3404 3405 3406

As with entity registration, the strength of the security infrastructure depends on the methods used for distributing the key to an RA or CA. There are many different methods, each appropriate for some range of applications. For example: •

The public key and the information identified in Sec. 7.1.5.1.1 are provided in person by the public-key owner or an authorized representative of the public-key owner (e.g., organization, device, process).

39 The naming authority is the entity responsible for the allocation and distribution of domain names, ensuring that the names are unique within the domain. A naming authority is often restricted to a particular level of domains, such as .com, .net, or .edu. 40 SP 800-56A also allows the use of predefined groups for finite-field Diffie-Hellman key agreement. POP cannot be performed using a digital signature when these parameters are used.

105

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417

•

Recommendation for Key Management Part 1 — General

The identity of the public-key owner or an authorized representative of the public-key owner is established and their authorization verified in person by the RA or CA during entity registration. At this time, the RA or CA provides unique, unpredictable information (e.g., authenticator, cryptographic key) to the owner or authorized representative as a secret value. The information identified in Sec. 7.1.5.1.1 and the public key are provided to the RA or CA using a communication protocol protected by the secret value. As specified in Sec. 7.3.4, the secret value should be destroyed by the key owner or owner’s representative after receiving confirmation that the certificate has been successfully generated. The RA or CA may maintain this secret value for auditing purposes, but the RA or CA should not accept further use of the secret value to prove identity.

3418 3419 3420 3421 3422 3423 3424 3425 3426

When a specific list of public-key owners is preauthorized to register keys, identifiers may be assigned without the owners being present. In this case, it is critical to protect the secret values from disclosure, and the procedures shall demonstrate that the chain of custody was maintained. The lifetime of the secret values should be limited but shall allow for the public-key owner or the owner’s representative to appear at the RA or CA, generate the keys, and provide the public key (under the secret value’s protection) to the RA or CA. Since it may take some time for the public-key owner or owner’s representative to appear at the RA or CA, a two or three-week lifetime for the secret value is reasonable.

3427 3428 3429 3430 3431

When public-key owners are not preauthorized, the RA or CA shall determine the identifier in the presence of the owner or representative. In this case, the time limit may be much more restrictive if the key pair is generated on-site and the public key is provided to the CA or RA. In this case, a 24-hour lifetime for the secret value would be reasonable.

3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442

•

The identity of the public-key owner is established at the RA or CA using a previous determination of the public-key owner’s identity. The continued authorization to receive a certificate is also verified. Recertification involves “chaining” a new publickey certificate request to a previously certified digital -signature key pair. For example, the request for a new public-key certificate is signed by the owner of the new public key to be certified. The private signature key used to sign the request should correspond to a public signature-verification key that was certified by the same CA that will certify the new public key. The request contains the new public key and any key-related information (e.g., key use and parameters). In addition, the CA shall obtain assurance of public-key validity and assurance that the owner possesses the corresponding private key.

3443 3444 3445 3446 3447 3448

•

The public key, key use, parameters, validity assurance information, and assurance of possession are provided to the RA or CA along with a claimed identity for the owner and the authorization to receive a certificate. The RA or CA delegates the verification of the public-key owner’s identity and authorization to another trusted process (e.g., an examination of the public-key owner’s identity by the U.S. Postal Service when delivering registered mail containing the requested certificate). Upon receiving a 106

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466

Recommendation for Key Management Part 1 — General

request for certification, the RA or CA generates and sends unique, unpredictable information (e.g., an authenticator or cryptographic key) to the requestor using a trusted process (e.g., registered mail sent via the U.S. Postal Service). The trusted process assures that the identity of the requestor is verified prior to delivery of the information provided by the RA or CA. The owner or owner’s representative uses this information to prove that the trusted process succeeded, and the RA or CA subsequently delivers the certificate to the owner or the owner’s representative. As specified in Sec. 7.3.4, the unique, unpredictable information should be destroyed by the key owner or representative after receiving confirmation that the certificate was successfully generated. The RA or CA may maintain this information for auditing purposes but should not accept further use of the unique identifier to prove identity. •

The public key and Domain Name System (DNS) addresses to be included in the common name or subject alternative names of the certificate are provided over a network connection to the RA via a certificate signing request. The RA confirms that the requestor is authorized to request a certificate for the DNS addresses by performing a challenge via the DNS record for the addresses, performing a challenge via Hypertext Transfer Protocol (HTTP) to the DNS addresses, or obtaining some other form of verification to confirm authorization for the DNS addresses.

3467 3468 3469 3470 3471 3472 3473 3474 3475

In cases that involve an RA, upon receipt of all information from the requesting entity (e.g., the owner of the new public key), the RA forwards the relevant information to a CA for certification. Together, the RA and CA shall perform any validation or other checks required for the algorithm with which the public key will be used (e.g., public-key validation) prior to issuing a certificate. The CA should indicate the checks or validations that will be or have been performed (e.g., in the certificate, certificate policy, or certification practice statement). After generation, the certificate is distributed manually or using automated protocols to the RA, the public-key owner or the owner’s representative, or a certificate repository (i.e., a directory) in accordance with the CA’s certification practice statement.

3476

7.1.5.1.1.3.

3477 3478

Static public keys may be distributed to entities other than an RA or CA in several ways, such as:

3479 3480 3481 3482

1. Manual distribution of the public key itself by the owner of the public key or the owner’s representative (e.g., in a face-to-face transfer or by a bonded courier): The mandatory assurances listed in Sec. 7.1.5.1.1 shall be provided to the recipient prior to operational use of the public key.

3483 3484 3485 3486 3487

2. Manual or automated distribution of a public-key certificate by the public-key owner, the owner’s representative, the CA, or a certificate repository (i.e., a directory): The mandatory assurances listed in Sec. 7.1.5.1.1 that are not provided by the CA (e.g., public-key validation) shall be provided to or performed by the receiver of the public key prior to the operational use of the key.

General Distribution of Static Public Keys

107

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

3488 3489 3490 3491

Recommendation for Key Management Part 1 — General

3. Automated distribution of a public key (e.g., using a communication protocol with authentication and content integrity): The mandatory assurances listed in Sec. 7.1.5.1.1 shall be provided to the receiving entity prior to operational use of the public key.

3492

7.1.5.1.2.

Distribution of Ephemeral Public Keys

3493 3494 3495 3496 3497 3498

When used, ephemeral public keys are distributed as part of a secure key-establishment protocol. The key-establishment process (i.e., the key-establishment scheme, protocol, key confirmation, any associated negotiation, and/or local processing) should provide a recipient with the assurances listed in Sec. 7.1.5.1.1. The recipient of an ephemeral public key shall obtain assurance of validity of that key, as specified in [SP 800-56A] or [SP 800-227], prior to using that key for subsequent steps in the key-establishment process.

3499

7.1.5.1.3.

3500 3501 3502 3503 3504 3505 3506 3507 3508 3509

When a static key pair is centrally generated, the key pair shall be generated within a [FIPS 140-3]-validated cryptographic module or obtained from another source that is approved by the U.S. Government for protecting national security information for subsequent delivery to the intended owner of the key pair. A signing key pair generated by a central key-generation facility for its subscribers will not provide strong support for non-repudiation for those individual subscribers. Therefore, when non-repudiation is required, the subscribers should generate their own signing key pairs. However, if the central key-generation facility generates signing key pairs for its own organization and distributes them to members of the organization, then support for non-repudiation may be provided at an organizational level (but not an individual level).

3510 3511 3512 3513 3514

The private key of a key pair generated at a central facility shall only be distributed to the intended owner of the key pair or provided to the owner’s representative for subsequent installation. The confidentiality of the centrally generated private key shall be protected, and the procedures for distribution shall include an authentication of the recipient’s identity and authorization as established during entity registration (see Sec. 7.1.1).

3515 3516 3517 3518 3519 3520 3521

The key pair may be distributed to the intended owner or owner’s representative using an appropriate manual method (e.g., courier, mail, or other method specified by the keygeneration facility) or secure automated method (e.g., a secure communication protocol). The private key shall be distributed in the same manner as a symmetric key (see Sec. 7.1.5.2.2). The distribution of the public key of a key pair is discussed in Sec. 7.1.5.1.1.3. During the distribution process, each key of the key pair shall be provided with the appropriate protections for that key (see Sec. 5.1).

3522 3523 3524 3525 3526

Upon receipt of the key pair, the owner shall obtain assurance of the validity of the public key (see [SP 800-56A], [SP 800-56B], [SP 800-89], and [SP 800-227]). The owner shall obtain assurance that the public and private keys of the key pair are a consistent pair (e.g., by checking that a key encrypted under a public key-transport key or a key encapsulated by a public encapsulation key can be decrypted by the corresponding private key).

Distribution of Centrally Generated Key Pairs

108

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3527

7.1.5.2. Generation and Distribution of Symmetric Keys

3528 3529 3530

The symmetric keys used for the encryption and decryption of data or other keys and for the computation of MACs shall be determined by an approved method and shall be provided with protection that is consistent with Sec. 5.

3531

Symmetric keys shall be:

3532 3533 3534 3535

1. Generated and subsequently distributed (see Sec. 7.1.5.2.1 and 7.1.5.2.2) manually (see Sec. 7.1.5.2.2.1), using a public key-transport mechanism (see Sec. 7.1.5.2.2.2), or using a previously distributed or agreed-upon key-wrapping key or KEM (see Sec. 7.1.5.2.2.2);

3536 3537

2. Established using a key-agreement scheme or KEM (i.e., the generation and distribution are accomplished with one process) (see Sec. 7.1.5.2.3); or

3538

3. Derived from a key-derivation key (see Sec. 7.2.4).

3539

7.1.5.2.1.

Key Generation

3540 3541 3542 3543 3544 3545

Symmetric keys shall be either 1) generated by an approved method (e.g., using an approved random number generator; see [SP 800-133]) or 2) derived from a key-derivation key (see Sec. 7.2.4) using an approved key-derivation function (see [SP 800-108]). Symmetric keys may also be generated using key-agreement or key-encapsulation techniques (see Sec. 7.1.5.2.3), in which case a separate key-distribution process is not required (e.g., see [SP 800-56A], [SP 800-56B], and [SP 800-227]).

3546 3547 3548 3549 3550 3551 3552 3553 3554

When split-knowledge procedures are used, the key shall only exist outside of a [FIPS 140-3] cryptographic module as multiple key shares. The key may be created within a cryptographic module and then split into shares for export from the module, or the key may be created as separate shares. Each key share shall provide no knowledge of the key value (i.e., each key share must appear to be generated randomly). If knowledge of k shares is required to construct the original key, then knowledge of any k−1 key share shall provide no information about the original key other than, possibly, its length. A suitable combination function is not provided by simple concatenation (e.g., it is not acceptable to form a 128-bit key by concatenating two 64-bit key shares).

3555 3556 3557

All keys and key shares shall be generated within a [FIPS 140-3]-validated cryptographic module or obtained from another source that is approved by the U.S. Government for the protection of national security information.

3558

7.1.5.2.2.

3559 3560 3561 3562

Keys generated in accordance with Sec. 7.1.5.2.1 as key-wrapping keys (i.e., key-encrypting keys), as key-derivation to be used for key derivation, or for the protection of communicated information are distributed manually (i.e., using manual key-transport procedures) or using an automated key-transport or KEM protocol.

Key Distribution

109

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3563 3564 3565

Keys that are only used to protect stored information (i.e., data or keying material) shall not be distributed except for backup or to other authorized entities that may require access to the stored information protected by the keys.

3566

7.1.5.2.2.1.

3567 3568 3569 3570 3571

Keys and key shares that are distributed manually (e.g., by other than an automated keytransport protocol) shall be protected throughout the distribution process. During manual distribution, secret keys, private keys, and key shares shall either be wrapped (i.e., encrypted with integrity protection), encapsulated, or distributed using appropriate physical security procedures.

3572 3573 3574

If split-knowledge procedures are used for key distribution (i.e., a key is distributed as key shares; see Sec. 7.1.5.2.1), each key share shall be distributed separately to its intended recipient.

3575 3576

The process for the manual distribution of secret keys, private keys, and key shares (i.e., secret keying material) shall ensure that:

Manual Key Distribution

3577

1. The keying material is distributed by an authorized source,

3578 3579

2. Any entity distributing plaintext keying material is trusted by both the entity that generates the keying material and any entity that receives the keying material,

3580

3. The keying material is protected in accordance with Sec. 5, and

3581

4. The keying material is received by authorized recipients.

3582 3583 3584 3585 3586 3587

When distributed in encrypted form, the key or key share shall either be 1) encapsulated using an approved KEM and a public encapsulation key owned by the intended recipient, 2) encrypted using an approved key-wrapping scheme and a key-wrapping key shared with the intended recipient, or 3) transported using an approved key-transport scheme and a public key-transport key owned by the intended recipient. The public key or key-wrapping key shall have been distributed as specified in this recommendation.

3588 3589 3590 3591

Physical security procedures may be used for all forms of manual key distribution. However, these procedures are particularly critical when the secret keying material is distributed in plaintext form. In addition to the assurances listed above, accountability and auditing of the distribution process should be used (see Sect. 8.3 and 8.4).

3592 3593

7.1.5.2.2.2. Automated Key Distribution, Key Transport, Key Encapsulation, and Key Wrapping

3594 3595

Automated key distribution may be used to distribute secret keys, private keys, and key shares via a communication channel (e.g., the internet). This requires the distribution or

110

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

3596 3597

Recommendation for Key Management Part 1 — General

establishment of a key-wrapping key (i.e., a key-encryption key), a public key-transport key, or public encapsulation key as follows:

3598 3599 3600

•

A key-wrapping key shall be generated and distributed in accordance with Sec. 7.1.5.2.1 and 7.1.5.2.2 or established using a key-establishment scheme, as defined in Sec. 7.1.5.2.3.

3601 3602

•

A public key-transport key or public static/ephemeral encapsulation key shall be generated and distributed, as specified in Sec. 7.1.5.1.

3603 3604

Only approved key-wrapping, public key-transport, or key-encapsulation schemes shall be used. The approved schemes provide assurance that:

3605 3606 3607 3608

•

For symmetric key-wrapping schemes: The key-wrapping key and the distributed keying material are not disclosed or modified. Approved key-wrapping methods that provide both confidentiality and integrity protection are provided or referenced in [SP 800-38F].

3609 3610 3611 3612 3613

•

For asymmetric key-transport schemes: The private key-transport key and the distributed keying material are not disclosed or modified, and correct association between the private and public key-transport keys is maintained. Approved keytransport schemes using asymmetric techniques are discussed in [SP 800-56A] and [SP 800-56B].

3614 3615 3616 3617

•

For key-encapsulation schemes: The private decapsulation key and the distributed ciphertext are not disclosed and/or modified, and correct association between the private and public keys is maintained. Approved key-encapsulation schemes using asymmetric techniques are discussed in [SP 800-227].

3618

•

The keying material is protected in accordance with Sec. 5.

3619 3620

In addition, the approved schemes and the associated key-establishment protocol should provide all of the following assurances:

3621 3622

•

Each entity in the key-distribution process knows the identifier associated with the other entities;

3623 3624

•

The keying material is correctly associated with the entities involved in the keydistribution process; and

3625 3626

•

The keying material has been received correctly (e.g., using a key-confirmation method).

3627

7.1.5.2.3.

3628 3629 3630 3631 3632

Key establishment using a key-agreement and/or key-encapsulation scheme is used in a communication environment to establish keying material with information contributed by all entities in the communication (most commonly, by only two entities). Only approved schemes shall be used. Approved key-agreement and key-encapsulation schemes using asymmetric techniques are provided in [SP 800-56A], [SP 800-56B], and [FIPS 203]. Key-

Key Agreement and Key Encapsulation

111

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3633 3634 3635 3636 3637

agreement schemes use asymmetric key pairs to calculate shared secrets, which are then used to derive symmetric keys and other keying material (e.g., IVs) without actually transmitting the keying material. Key encapsulation uses the public key of the intended recipient and a random value generated by the sending entity to generate ciphertext from which the recipient can derive the keying material.

3638 3639 3640 3641

A key-agreement or key-encapsulation scheme uses either static or ephemeral asymmetric key pairs or both. The asymmetric key pairs should be generated and distributed, as discussed in Sec. 7.1.5.1. Keying material derived using these schemes shall be protected, as specified in Sec. 5.

3642 3643

A key-agreement or key-encapsulation scheme and its associated key-establishment protocol should provide the following assurances:

3644 3645 3646 3647 3648

•

3649 3650 3651 3652 3653

The identifiers for entities involved in the key-establishment protocol are correctly associated with those entities. Assurance for the association of identifiers to entities may be achieved by the scheme or the protocol in which it is performed. The identifier may be a “pseudo-identifier” (a pseudonym) rather than, for example, the identifier that appears on the entity’s birth certificate. In general, an identifier is associated with each entity involved in the keyestablishment protocol, and each entity must be able to associate all the other entities with their appropriate identifiers. In special cases, such as the secure distribution of public information on a website, the association with an identifier may only be required for a subset of the entities (e.g., only the server).

3654 3655

•

The keys used in the key-agreement or key-encapsulation scheme are correctly associated with the entities involved in the key-establishment process.

3656 3657

•

The resulting keying material is correct (e.g., determined using a key-confirmation method).

3658 3659 3660

Keying material that results from the key-agreement or key-encapsulation scheme and its enabling protocol shall not be used to protect or send information until the three assurances described above have been obtained.

3661

7.1.5.3. Generation and Distribution of Other Keying Material

3662 3663 3664

Keys are often generated in conjunction with or used with other keying material. This other keying material shall be protected in accordance with Sec. 5.2. Table 8 specifies the types of protection required for keying material other than keys.

3665

7.1.5.3.1.

3666 3667 3668 3669

Algorithm parameters are used by some asymmetric-key algorithms to generate key pairs and in the execution of their basic functions. Algorithm parameters may be provided in the algorithm specifications, distributed in the same manner as the public keys with which they are associated, or be made available at some accessible location. Assurance of the validity of

Algorithm Parameters

112

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3670 3671 3672 3673 3674 3675

the algorithm parameters shall be obtained prior to use, either by a trusted entity that vouches for the parameters (e.g., a CA) or by the entities that use them. Assurance of algorithm-parameter validity is addressed in [SP 800-56A], [SP 800-56B], [FIPS 203] (for keyagreement and key-encapsulation schemes), and [SP 800-89] (for digital signatures). Obtaining this assurance should be addressed in a CA’s certification practices statement or an organization’s security plan.

3676

7.1.5.3.2.

3677 3678 3679 3680 3681 3682

Initialization vectors (IVs) are used by symmetric-key algorithms in several modes of operation for encryption and decryption, for authentication, or both. The criteria for the generation and use of IVs are provided in the SP 800-38 series of publications. IVs shall be protected as specified in Section 5.1.2. IVs may be distributed in the same manner as their associated keys or may be distributed with the information that uses the IVs as part of the cryptographic mechanism.

3683

7.1.5.3.3.

3684 3685 3686 3687

Shared secrets are computed during the execution of an asymmetric key-agreement scheme and are subsequently used to derive keying material. Shared secrets are generated as specified by an appropriate key-agreement scheme (see [SP 800-56A] and [SP 800-56B]) and shall not be distributed nor used directly as keying material.

3688

7.1.5.3.4.

3689 3690 3691 3692 3693

Seeds are used to initialize a deterministic algorithm within an RBG or to generate keying material from a value provided by an RBG. Approved RBGs are specified in the SP 800-90 series of publications, and each RBG includes a deterministic component that is referred to as a Deterministic Random Bit Generator (DRBG). RBGs depend on the introduction of truly random bits that are used to generate the seeds for:

Initialization Vectors (IVs)

Shared Secrets Generated During Key Agreement

Seeds

3694 3695 3696

•

Initializing a DRBG. These seeds must be kept secret. An initialized DRBG is often used to generate keys and other values that require unpredictability. The seeds themselves shall not be used for any purpose other than as DRBG input.

3697

•

Otherwise determining keying material in accordance with an algorithm specification.

3698 3699 3700

The output of an RBG is sometimes used as a seed to generate or regenerate keying material rather than initialize a DRBG. In this case, the seed needs to be protected to ensure that the resulting keying material remains secure.

3701

7.1.5.3.5.

3702 3703 3704

Public and secret information may be used during the seeding of the DRBG within an RBG (see Sec. 7.1.5.3.4) or during the generation or establishment of keying material (see [SP 80056A], [SP 800-56B], [SP 800-108], and [SP 800-227]). Public information may be distributed,

Other Public and Secret Information

113

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3705 3706

but secret information shall be protected in the same manner as a private or secret key during distribution.

3707

7.1.5.3.6.

3708 3709

Intermediate results occur during computation using cryptographic algorithms. These results shall not be distributed as or with the keying material.

3710

7.1.5.3.7.

3711 3712 3713 3714

Random bits (or numbers) are used for many purposes, including the generation of keys, nonces, seeds for generating other values, and the issuing of challenges during the execution of communication protocols. Random bits may be distributed, but whether confidentiality protection is required depends on the context in which the random bits are used.

3715

7.1.5.3.8.

3716 3717 3718 3719 3720 3721 3722 3723 3724 3725

Passwords are used for identity authentication, authorization, and, in some cases, to derive keying material (see [SP 800-132]). Passwords may be distributed, but their protection during distribution shall be consistent with the protection required for their use. For example, if the password will be used to access cryptographic keys that are used to provide 128 bits of security strength when protecting data, then the password needs to be provided with at least 128 bits of protection as well. Poorly selected passwords may not provide the required amount of protection for key access and are potentially the weak point of the process (i.e., it may be far easier to guess the password than to attempt to “break” the cryptographic protection used on the password). It is the responsibility of users and organizations to select passwords that provide the requisite amount of protection for the keys they protect.

3726

7.1.6. Key Registration Function

3727 3728 3729 3730 3731 3732 3733 3734 3735 3736

Key registration results in the binding of keying material to information associated with a particular entity. Keys that would be registered include the public key of an asymmetric key pair and the symmetric key used to bootstrap an entity into a system. Normally, keys generated during communications (e.g., using key-agreement schemes, key encapsulation, or key derivation functions) would not be registered. Information provided during registration typically includes the identifier of the entity associated with the keying material (i.e., the owner) and the intended use of the keying material (e.g., as a signing key or dataencryption key). Additional information may include authorization information, specify a level of trust, or indicate where the key is stored (e.g., its physical location, internet address, device identity).

3737 3738 3739

The binding is performed after the entity’s identity has been authenticated by a means that is consistent with the system policy (see Sec. 7.1.1). The binding provides assurance to the community at large that the keying material is used by the correct entity in the correct

Intermediate Results

Random Bits/Numbers

Passwords

114

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3740 3741 3742

application. The binding is often cryptographic to create a strong association between the keying material and the entity. A trusted third party (e.g., Kerberos realm server or PKI CA) performs the binding. Identifiers issued by a trusted third party shall be unique to that party.

3743 3744 3745 3746 3747 3748 3749

When a Kerberos realm server performs the binding, a symmetric key is stored on the server with the corresponding metadata. In this case, the registered keying material is maintained in secure storage (i.e., the keys are provided with confidentiality and integrity protection during storage). When a CA performs the binding, the public key and associated information (e.g., algorithm parameters and some metadata, often called attributes) are placed in a public-key certificate that is digitally signed by the CA. In this case, the registered keying material may be made publicly available.

3750 3751 3752 3753

When a CA provides a certificate for a public key, the public key shall be verified to ensure that it is associated with the private key known by the purported owner of the public key. This provides assurance of possession (i.e., POP). When POP is used to obtain assurance of possession, the assurance shall be accomplished, as specified in Sec. 7.1.5.1.1.2.

3754

Registered keys and certificates shall be included in an inventory (see Sec. 8.2).

3755

7.2. Operational Phase

3756 3757 3758 3759 3760 3761

Keying material used during the cryptoperiod of a key is often stored for access as needed. During storage, the keying material and other key information shall be protected, as specified in Sec. 5.2.2. During normal use, the key information is stored in the device or module that uses that information or on an immediately accessible storage media. Keying material is acquired from storage when required for operational use and not present in active memory within the device or module.

3762 3763 3764 3765 3766 3767 3768 3769

To provide continuity of operations when the keying material becomes unavailable for use from normal operational storage during its cryptoperiod (e.g., because the material is lost or corrupted), keying material may need to be recoverable. If an analysis of system operations indicates that the keying material needs to be recoverable, then the keying material shall be backed up (see Sec. 7.2.2.1) or archived (see Sec. 7.3.1), or the system shall be designed to allow reconstruction (e.g., re-derivation) of the keying material. Retrieving or reconstructing keying material from an archive or backup storage is commonly known as key recovery (see Sec. 7.2.2.2).

3770 3771 3772 3773 3774

At the end of a key’s cryptoperiod, a new key needs to be available to replace the old key if operations are to continue. This can be accomplished by re-keying (see Sec. 7.2.3.1) or by key derivation (see Sec. 7.2.4). A key should be destroyed as soon as that key is no longer needed to reduce the risk of exposure; when destroyed, the key shall be destroyed in accordance with Sec. 7.3.4.

3775

7.2.1. Normal Operational Storage Function

3776 3777

One objective of key management is to facilitate the operational availability of keying material for standard cryptographic purposes. Usually, a key remains operational until the 115

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3778 3779 3780

end of the key’s cryptoperiod (i.e., the expiration date). During normal operational use, keying material is available in the device or module (e.g., in RAM) or in an immediately accessible storage media (e.g., on a local hard drive).

3781

7.2.1.1. Cryptographic Module Storage

3782 3783 3784 3785

Keying material may be stored in a cryptographic module that adds, checks, or removes the cryptographic protection on information. The storage of the keying material shall be consistent with both Sec. 5.2.2 and [FIPS 140-3]. Additional storage-media discussions are provided in Sec. 5.2.2.7.

3786

7.2.1.2. Immediately Accessible Storage Media

3787 3788 3789

Keying material may need to be stored for normal cryptographic operations on an immediately accessible storage media (e.g., a local hard drive) during the cryptoperiod of the key. The storage requirements of Sec. 5.2.2 shall apply to this keying material.

3790

7.2.2. Continuity of Operations Function

3791 3792 3793 3794 3795 3796 3797

Keying material can become lost or unusable due to hardware damage, corruption, the loss of program or data files, system policy, or configuration changes. To maintain continuity, it is often necessary for users and/or administrators to be able to recover keying materials from backup storage. However, if operations can be continued without the backup of keying material (e.g., by re-keying) or the keying material can be recovered or reconstructed without being saved, it may be preferable not to save the keying material to lessen the possibility of a compromise of the keying material or other cryptographically related information.

3798 3799 3800 3801

The compromise of keying material affects the continuity of operations (see Sec. 8.5). When keying material is compromised, the continuity of operations requires the establishment of entirely new keying material (see Sec. 7.1.5) following an assessment of the keying material that was affected. All affected keying material needs to be replaced.

3802

7.2.2.1. Backup Storage

3803 3804 3805 3806 3807 3808 3809 3810

The backup of keying material on an independent, secure storage media provides a source for key recovery (see Sec. 7.2.2.2). Backup storage is used to store copies of key information that is also currently available in normal operational storage during a key’s cryptoperiod (i.e., in the cryptographic module or on an immediately accessible storage media; see Sec. 7.2.1.1). Not all keys need to be backed up, and others need additional protections. For example, additional protection needs to be provided for the backup of keys for stateful hash-based signatures due to the high risk associated with reusing the one-time private keys. The storage requirements of Sec. 5.2.2 apply to keying material that is backed up.

3811 3812

Keying material maintained in backup storage should remain in storage for at least as long as the same keying material is maintained for normal operational use (see Sec. 7.2.1). When no 116

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3813 3814 3815

longer needed for normal operational use, the keying material and other related information should be removed from backup storage. When removed from backup storage, all traces of the information in backup storage shall be destroyed in accordance with Sec. 7.3.4. 41

3816 3817 3818 3819 3820

Table 10 and Table 11 provide guidelines for backing up each type of keying material and other related information. An “OK” indicates that storage is permissible but not necessarily required. The final determination for backup should be made based on the application in which the keying material is used. A detailed discussion about the backup of each type of key and other key information is provided in Appendix B.1.3.

3821

Table 10. Backup of keys Type of Key

Backup Digital Signatures

1. Private signature key

No (in general); support for non-repudiation would be in question. However, backup may be warranted in some cases, such as a CA’s private signing key. When required, any backed up keys shall be stored under the owner’s control.

2. Public signature-verification key

OK; its presence in a public-key certificate that is available elsewhere may be sufficient. Authentication

3. Symmetric authentication key

OK

4. Private authentication key

OK if required by an application.

5. Public authentication key

OK if required by an application. Random Bit Generation

6. Random number generation key

Not necessary and may not be desirable, depending on the application. Key Derivation

7. Symmetric key-derivation

OK Key Establishment (automated)

8. Symmetric key-wrapping/unwrapping key

OK

9. Public key-transport key

OK; its presence in a public-key certificate that is available elsewhere may be sufficient.

10, Private key-transport key

OK

11. Symmetric key-agreement key

OK

12. Public static key-agreement key

OK; its presence in a public-key certificate that is available elsewhere may be sufficient.

13. Private static key-agreement key

OK

14. Public ephemeral key-agreement key

OK

15. Private ephemeral key-agreement key

OK

41 A discussion of backup and recovery is provided in [ITLBulletin].

117

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

Type of Key

Backup

16. Public static encapsulation key

OK; its presence in a public-key certificate that is available elsewhere may be sufficient.

17. Private static decapsulation key

OK

18. Public ephemeral encapsulation key

No; it is only to be used for a single key-encapsulation process.

19. Private ephemeral decapsulation key

OK until no longer required for decapsulation of the (only) encapsulated keys.

Data Encryption/Decryption 20. Symmetric data encryption/decryption key (data in transit)

OK

21. Symmetric data encryption/decryption key (data at rest)

OK

Key Storage (for operational, backup, and archive storage) 22. Symmetric key-wrapping/unwrapping key

OK

23. Public key-wrapping key

OK

24.Private key-unwrapping key

OK

25. Public encapsulation key

OK

26.Private decapsulation key

OK Authorization

27. Symmetric authorization key

OK

28. Private authorization key

OK

29. Public authorization key

OK; its presence in a public-key certificate that is available elsewhere may be sufficient.

3822

Table 11. Backup of other related information Type of Keying Material Algorithm parameters Initialization vector Shared secret Seed Other public information Other secret information Intermediate results Key-control information/metadata (e.g., IDs or purpose) Random number Passwords Audit information

Backup? OK OK if necessary No No for DRBG initialization; otherwise, OK OK OK No OK Depends on the application or use of the random number. OK when used to derive keys or to detect the reuse of passwords; otherwise, No. OK

118

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3823

7.2.2.2. Key Recovery Function

3824 3825 3826 3827 3828

Keying material that is in active memory or stored in normal operational storage may sometimes be lost or corrupted (e.g., from a system crash or power fluctuation). Some of the keying material is needed to continue operations and cannot be easily replaced. An assessment needs to be made about which keying material needs to be preserved for possible recovery at a later time.

3829 3830

The decision about whether key recovery is required should be made on a case-by-case basis. The decision should be based on:

3831

•

The type of key (e.g., private signature key or symmetric data-encryption key),

3832 3833

•

The application in which the key will be used (e.g., interactive communications or file storage),

3834 3835 3836

•

Whether the key is “owned” by the local entity (e.g., a private key), owned by another entity (e.g., the other entity’s public key), or shared (e.g., a symmetric data-encryption key shared by two entities),

3837

•

The role of the entity in a communication (e.g., sender or receiver), and

3838 3839 3840

•

The algorithm or computation in which the key will be used (e.g., whether the entity has the necessary information to perform a given computation if the key were to be recovered). 42

3841 3842 3843 3844 3845 3846 3847

The factors involved in a decision for or against key recovery should be carefully assessed. The trade-offs are concerned with the continuity of operations versus the risk of possibly exposing the keying material and the information it protects if control of the keying material is lost. If it is determined that a key needs to be recovered, and the key is still active (e.g., the cryptoperiod of the key has not expired, and the key has not been compromised), the key could be replaced rather than recovered in order to limit the exposure of the data protected by the lost key (see Sec. 7.2.3).

3848 3849

Issues associated with key recovery and discussions about whether different types of cryptographic material need to be recoverable are provided in Appendix B.

3850

7.2.3. Key Change Function

3851 3852

Key change is the replacement of a key with another key that performs the same function as the original key. There are several reasons for changing a key, such as:

3853

1. The key may have been compromised.

3854

2. The key’s cryptoperiod may be nearing expiration.

3855

3. It may be desirable to limit the amount of data protected with any given key.

42 This could be the case when performing a key-establishment process for some key-establishment schemes (see [SP 800-56A] and [SP 80056B]).

119

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3856

7.2.3.1. Re-Keying

3857 3858 3859 3860 3861

If a new key is generated in a manner that is entirely independent of the “value” of the old key, the process is known as re-keying. Replacement shall be accomplished using one of the key-establishment methods discussed in Sec. 7.1.5. Re-keying is used when a key has been compromised (provided that the re-keying scheme itself is not compromised) or when the cryptoperiod has expired or is nearing expiration.

3862

7.2.3.2. Key Update Function

3863 3864 3865 3866 3867 3868

If the “value” of a new key depends on the value of the old key, the process is known as key update (e.g., the current key is modified in some way to create a new key). Key update is a special case of key derivation (see Sec. 7.2.4) in which a derived key replaces the key used to derive it. For example, suppose that K1 is used as an encryption key. When K1 needs to be replaced, it is used to derive K2. K2 is then used as the new encryption key until it is replaced by K3, which is derived from K2.

3869 3870 3871

Key update could result in a security exposure if an adversary obtains a key in the chain of derived keys and knows the update process that was used. Keys derived from a compromised key in the chain could then be easily determined.

3872

Federal applications shall not use key update (also see [SP 800-152]).

3873

7.2.4. Key Derivation Methods

3874 3875 3876 3877 3878 3879 3880

Cryptographic keys may be derived from a secret value. The secret value and other information are input into a key-derivation method (e.g., a key-derivation function) that outputs the required keys). The key-derivation method shall be nonreversible (i.e., a one-way function) so that the secret value cannot be determined from the derived keys. In addition, it shall not be possible to determine a derived key from other derived keys. It should be noted that the strength of a derived key is no greater than the strength of the derivation algorithm and the secret value from which the key is derived.

3881

Three commonly used key-derivation cases are discussed below.

3882 3883 3884 3885 3886 3887 3888 3889 3890

1. Two parties derive common keys from a common shared secret. This approach is used in the key-agreement techniques specified in [SP 800-56A] and [SP 800-56B]. The security of this process depends on the security of the shared secret and the specific key-derivation method used. If the shared secret is known, the derived keys can be determined. A key-derivation method specified or allowed in [SP 800-56C] shall be used for this purpose. These derived keys may be used to provide the same confidentiality, identity authentication, and source authentication services as randomly generated keys. The security strength of the derived keys is determined by the scheme and key pairs used to generate the shared secret.

3891 3892

2. Keys derived from a key-derivation key (master key). This is often accomplished by using a secret key-derivation key and other known secret or public information as

120

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3893 3894 3895 3896 3897 3898 3899

input to a function that generates the keys. One of the key-derivation functions defined in [SP 800-108] or [SP 800-135] shall be used for this purpose. The security of this process depends on the security of the key-derivation key and the key-derivation method. If the key-derivation key is known by an adversary, any of the derived keys can be generated. Therefore, keys derived from a key-derivation key are only as secure as the key-derivation key itself. If the key-derivation key is kept secret, the derived keys may be used in the same manner as randomly generated keys.

3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914

3. Keys derived from a password. A user-generated password is inherently less random (i.e., has lower entropy) than is required for a cryptographic key. That is, the number of passwords that are likely to be used to derive a key is significantly smaller than the number of keys that are possible for a given key size. To increase the difficulty of exhaustively searching the likely passwords, a key-derivation function is iterated a large number of times. The key is derived using a password and other known secret or public information as input to the key-derivation function. The security of the derived key depends on the security of the password and the key-derivation process. If the password is known or can be guessed, then the corresponding derived key can be generated. Therefore, keys derived in this manner are likely to be less secure than randomly generated keys or keys derived from a shared secret or secret keyderivation key. For storage applications, one of the key-derivation functions specified in [SP 800-132] shall be used to derive keys from passwords. For non-storage applications, keys derived in this manner shall not be used for general encryption but may sometimes be used for identity and source authentication purposes.

3915

7.3. Post-Operational Phase

3916 3917 3918

During the post-operational phase, keying material is no longer in operational use, but access to the required keying material may still be possible for processing already protected information.

3919

7.3.1. Key Archive and Key Recovery Functions

3920 3921 3922

A key archive is a repository that contains keys and their associated information (i.e., key information) for recovery beyond the cryptoperiod of the keys. Not all keys need to be archived. An organization’s security plan should discuss key archiving (see [SP 800-57p2]).

3923 3924 3925 3926 3927 3928

The key archive shall continue to provide the appropriate protections for each key and any other related information in the archive, as specified in Sec. 5.2.2. The archive will require a strong access-control mechanism to limit access to the archive information to only authorized entities. When key information is entered into the archive, it is often timestamped so that the date of entry can be determined. This date may itself be cryptographically protected so that it cannot be changed without detection.

3929 3930 3931

If a key must be recoverable (e.g., after the end of its cryptoperiod), either the key shall be archived, or the system shall be designed to allow reconstruction (e.g., re-derivation) of the key from archived information. Retrieving the key from archive storage or by reconstruction 121

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3932 3933

is commonly known as key recovery. The archive shall be maintained by a trusted party (e.g., the organization associated with the key or a trusted third party).

3934 3935 3936 3937 3938

Archived key information shall be stored separately from operational data, and multiple copies of archived key information should be provided in physically separate locations (i.e., the key archive should be backed up). For critical information that is protected (i.e., encrypted, wrapped, or encapsulated) under archived keys, it may be necessary to back up the archived keys and store multiple copies of these archived keys in separate locations.

3939 3940 3941

When archived, keys should be archived prior to the end of the key’s cryptoperiod. For example, it may be prudent to archive the key when it is activated. When no longer required, the key shall be destroyed in accordance with Sec. 7.3.4.

3942 3943 3944 3945 3946 3947

The confidentiality of archived key information is provided by an archive-confidentiality key (i.e., one or more encryption, wrapping, or encapsulation keys that are used exclusively to protect the confidentiality of archived key information), by another key that has been archived, or by a key that may be derived from an archived key. The algorithm with which an archive-confidentiality key is used may also provide integrity protection for the archived information.

3948 3949 3950 3951

When an archive-confidentiality key and its associated algorithm do not also provide integrity protection for the archived information, integrity protection shall be provided by a separate archive-integrity key (i.e., one or more authentication or digital signature keys that are used exclusively for the archive) or by another key that has been archived.

3952 3953 3954 3955 3956

When the confidentiality and integrity protection of the archived key information are provided using separate processes, the archive-confidentiality key and archive-integrity key shall be different from each other (e.g., independently generated) and shall be protected in the same manner as their key type (see Sec. 5.1.1). These two services could also be provided using a single cryptographic algorithm and a single key.

3957 3958 3959 3960 3961

Table 12 and Table 13 indicate the appropriateness of archiving keys and other cryptographically related information. An “OK” in column 2 (Archive?) indicates that archiving is permissible but not necessarily required. Column 3 (Retention period) indicates the minimum time that the key should be retained in the archive. Additional advice on the storage of keying material in archive storage is provided in Appendix B.1.3.

3962

Table 12. Archive of keys Type of Key

Archive?

Retention period (minimum)

Digital Signatures 1. Private signature key 2. Public signature-verification key

No Until no longer required to verify data signed with the corresponding private signature key

OK

Authentication 3. Symmetric authentication key 4. Private authentication key

Until no longer needed to authenticate data or an identity

OK No

122

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025 Type of Key

Recommendation for Key Management Part 1 — General Archive?

5. Public authentication key

Retention period (minimum)

OK Random Bit Generation

6. Symmetric random number generator key

No Key Derivation

7. Symmetric key-derivation/master key

OK, if needed to derive other keys for archived data

Until no longer needed to derive other keys

Key Establishment (automated) 8.Symmetric keywrapping/unwrapping key

OK

Until no longer needed to unwrap keys that were wrapped by this key

9. Public key-transport key

OK

No real use after its cryptoperiod

OK

Until no longer needed to decrypt keys encrypted by the corresponding public keytransport key

OK

Until no longer useful for determining the key agreed upon

OK

Until no longer needed to reconstruct keying material

13. Private static key-agreement key

OK

Until no longer useful for determining the key agreed upon

14. Public ephemeral keyagreement key

OK

Until no longer useful for determining the key agreed upon

15. Private ephemeral keyagreement key

No

16. Public static encapsulation key

OK

No real use after its cryptoperiod

OK

Until no longer needed to decapsulate keys that were encapsulated by the corresponding public static encapsulation key

10. Private key-transport key

11. Symmetric key-agreement key 12. Public static key-agreement key

17. Private static decapsulation key

18. Public ephemeral encapsulation key 19. Private ephemeral decapsulation key

No Until no longer needed to decapsulate the key that was encapsulated by the corresponding public ephemeral encapsulation key

OK

Data Encryption/Decryption 20. Symmetric data encryption/decryption keys: (data in transit) 21. Symmetric data encryption/decryption key: (data at rest)

Until no longer needed to decrypt data that was encrypted by this key

OK

Key Storage (for operational, backup, and archive storage)

123

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025 Type of Key

Recommendation for Key Management Part 1 — General Archive?

Retention period (minimum)

22. Symmetric keywrapping/unwrapping key

OK

Until no longer needed to unwrap keys that were wrapped by this key

23. Public key-wrapping key

OK

No real use after its cryptoperiod

24.Private key-unwrapping key

OK

Until no longer needed to unwrap keys that were wrapped by the corresponding public keywrapping key

25. Public encapsulation key

OK

No real use after its cryptoperiod

26.Private decapsulation key

OK

Until no longer needed to decapsulate keys that were encapsulated by the corresponding public encapsulation key

Authorization Symmetric authorization key

No

Private authorization key

No

Public authorization key

3963

Table 13. Archive of other related information Type of Key Algorithm parameters Initialization vector

Shared secret Seed Other public information Other secret information Intermediate result Key-control information/metadata (e.g., IDs, purpose) Random number Password

Audit information

3964 3965 3966 3967

No real use after the cryptoperiod of the corresponding private authorization key

OK

Archive? OK OK; normally stored with the protected information No No OK OK No OK

OK when used to derive keys or to detect the reuse of passwords; otherwise, No OK

Retention period (minimum) Until all keying material, signatures, and signed data using the algorithm parameters are removed from archives Until no longer needed to process the protected data

Until no longer needed to process data using the public information Until no longer needed to process data using the secret information Until the associated key is removed from the archive Depends on the application or use of the random number Until no longer needed to derive or rederive keys or to detect password reuse

Until no longer needed

The recovery of archived keying material may be required to remove (e.g., decrypt) or check (e.g., verify a digital signature or MAC) the cryptographic protections on other archived data. Recovered keys shall not be used to apply cryptographic protection if the cryptoperiod (or originator-usage period) of those keys has expired. The key-recovery process results in 124

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

3968 3969 3970 3971 3972 3973

retrieving or reconstructing the desired keying material that is retrieved from archive storage to perform the required cryptographic operation. Immediately after completing this operation, the keying material shall be erased from the cryptographic process 43 for which it was recovered (i.e., it shall not be used for normal operational activities). However, the key shall be retained in the archive (see Sec. 7.3.4) as long as needed. Further guidelines concerning key-recovery issues is provided in Appendix B.

3974

7.3.2. Entity De-Registration Function

3975 3976 3977 3978 3979

The entity de-registration function removes the authorizations of an entity to participate in a security domain. When an entity ceases to be a member of a security domain, the entity shall be de-registered. De-registration is intended to prevent other entities from relying on or using the de-registered entity’s keying material (e.g., a symmetric key shared with the de-registered entity).

3980 3981 3982 3983 3984 3985 3986

All records of the entity and the entity’s associations shall be marked to indicate that the entity is no longer a member of the security domain, but the records should not be deleted, even though the key itself has been destroyed. To reduce confusion and unavoidable human errors, identification information associated with the de-registered entity should not be reused (at least for a period of time). For example, if a “John Wilson” retires and is de-registered on Friday, the identification information assigned to his son “John Wilson,” who is hired the following Monday, should be different.

3987

7.3.3. Key De-Registration Function

3988 3989 3990 3991 3992 3993

Registered keying material may be associated with the identity of a key owner, owner information (e.g., email address), role, or authorization information. When the keying material is no longer needed or the associated information becomes invalid, the keying material should be de-registered (i.e., all records of the keying material and its associations should be marked to indicate that the key is no longer in use) by the appropriate trusted third party. In general, this will be the trusted third party that registered the key (see Sec. 7.1.6).

3994 3995 3996 3997 3998 3999

Keying material should be de-registered when the information associated with an entity is modified. For example, if an entity’s email address is associated with a public key and the entity’s address changes, the keying material should be de-registered to indicate that the associated information has become invalid. Unlike the case of a key compromise, if the cryptoperiod of the key has not expired, the entity could safely re-register the public key after modifying the entity’s information through the entity registration process (see Sec. 7.1.1).

4000 4001 4002 4003

When a registered cryptographic key is compromised, that key and any associated keying material shall be de-registered. When the compromised key is the private key of a key pair, the public key shall also be revoked (Sec. 7.3.5). The de-registered key shall not be reregistered. 43 For example, an archived symmetric key could be recovered to decrypt a single message or file or could be used to decrypt multiple messages or files, all of which were encrypted using that key during its originator-usage period.

125

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4004 4005 4006

If the registration information associated with a key pair is changed but the private key has not been compromised, the public key should be revoked with an appropriate reason code (see Sec. 7.3.5). In this case, the key may be re-registered if the cryptoperiod has not expired.

4007

7.3.4. Key Destruction Function

4008 4009 4010 4011 4012 4013 4014

When copies of cryptographic keys are made, care should be taken to provide for their eventual destruction (e.g., the identity of sharing parties could be recorded in the key’s metadata). All copies of a private or secret (symmetric) key shall be destroyed as soon as they are no longer required (e.g., for archival or reconstruction activity) to minimize the risk of a compromise. Secret and private keys shall be destroyed in a manner that removes all traces of the keys so that they cannot be recovered by either physical or electronic means. 44 Public keys may be retained or destroyed as desired.

4015

7.3.5. Key Revocation Function

4016 4017 4018 4019 4020 4021 4022 4023

Key revocation is used if 1) the authorized use of a key needs to be terminated prior to the end of the established cryptoperiod of that key, or 2) a key whose usage period or cryptoperiod has expired has been compromised. A key may be revoked for administrative reasons (e.g., the key’s owner has left the organization or a device containing the key has been removed from service), or it may be revoked on an emergency basis if there is reason to believe that it may have been disclosed to or otherwise accessed by an unauthorized entity. In either case, a cryptographic key should be revoked as soon as feasible after the need for revocation has been determined.

4024 4025

Entities that have been, are, or would be using the key (e.g., relying parties) need to be notified that the key has been revoked.

4026 4027 4028

•

When a (secret) symmetric key is revoked, all entities sharing the key need to be notified (e.g., using a compromised key list [CKL] or a specific notification provided to each entity sharing the key).

4029 4030 4031 4032 4033

•

In the case of asymmetric key pairs, the revocation refers to the private key. However, when public-key certificates are used, the certificate containing the public key corresponding to the private key is revoked, and relying parties are notified using, for example, certificate revocation lists (CRLs) or the Online Certificate Status Protocol (OCSP).

4034 4035 4036 4037

The notification could be provided by actively sending a notification to all entities that might be using the revoked key or by allowing the entities to request the key’s status (i.e., a “push” or a “pull” of the status information). The notification should include a complete identification of the key (excluding the key itself), the date and time of revocation, and the A simple deletion of the keying material might not completely obliterate the information. For example, erasing the information might require overwriting that information multiple times with other unrelated information, such as random bits or all zero or one bits. Keys stored in memory for a long time can become “burned in.” This can be mitigated by splitting the key into components that are frequently updated (see [DiCrescenzo]).

44

126

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4038 4039 4040

reason for revocation when appropriate (e.g., a key compromise). Based on the revocation information provided, other entities could then determine how they will treat information that was protected by the revoked key.

4041 4042 4043 4044 4045 4046 4047 4048 4049

For example, if a public signature-verification key is revoked because an entity left an organization, it may be appropriate to honor all signatures created prior to the revocation date (i.e., to continue to verify those signatures and accept them as valid if the verification is successful). If a signing private key is compromised, resulting in the revocation of the corresponding public key, an assessment needs to be made about whether information signed prior to the date in the revocation notice would be considered valid. As another example, a symmetric key that is used to generate MACs may be revoked so that it will not be used to generate MACs on new information. However, the key may be retained so that the MAC on archived documents can be verified.

4050 4051 4052 4053 4054 4055 4056 4057

The details for key revocation should reflect the life cycle for each particular key. If a key is used in a pairwise situation (e.g., two entities communicating using the same symmetric encryption key), the entity revoking the key shall inform the other entity of the revocation. If the key has been registered with an infrastructure (e.g., a particular PKI), the entity revoking the key cannot always directly inform the other entities that may rely upon that key. Instead, the entity revoking the key shall inform the infrastructure that the key needs to be revoked (e.g., using a certificate revocation request). The infrastructure shall respond by revoking and de-registering the key (see Sec. 7.3.3).

4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068

In a PKI, key revocation is commonly achieved by including the certificate in a list of revoked certificates (i.e., in a CRL). If the PKI uses an online status mechanism (e.g., the Online Certificate Status Protocol in RFC 2560 [RFC 2560]), revocation is achieved by informing the appropriate certificate status servers. For example, when a private key is compromised, the corresponding public-key certificate shall be revoked as soon as possible. Certificate revocation because of a key compromise indicates that the binding between the owner and the key can no longer be trusted. Relying parties should not accept the certificate without seriously considering the risks and consulting the organization’s policy about this situation. Other revocation reasons indicate that even though the original binding may still be valid, and the key was not compromised, the use of the public key in the certificate should be terminated. Again, the relying party should consult the organization’s policy on this issue.

4069 4070 4071 4072

In a symmetric-key system, key revocation could theoretically be achieved by simply deleting the key from the server’s storage. Key revocation for symmetric keys is more commonly achieved by adding the key to a compromised key list, which helps satisfy auditing and management requirements.

4073

7.4. Destroyed Phase

4074 4075 4076 4077

The key is no longer available. All records of its existence may have been deleted, although this is not required. Some organizations may require the retention of certain metadata elements for audit purposes. For example, if a copy of an ostensibly destroyed key is found in an uncontrolled environment or is later determined to have been compromised, records

127

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4078 4079

of the key’s identifier, its type, and its cryptoperiod may be helpful in determining what information was protected under the key and how best to recover from the compromise.

4080 4081 4082 4083 4084 4085 4086

In addition, by keeping a record of the metadata of both destroyed and compromised keys, one can determine which keys transitioned through a normal life cycle and which were compromised at some time during their life cycle. Thus, protected information that is linked to key names that went through the normal life cycle may still be considered secure, provided that the security strength of the algorithm remains sufficient. However, any protected information that is linked to a key name that has been compromised may itself be compromised.

4087

128

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4088

8. Additional Considerations

4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099

Many aspects of key management can be handled by a key-management system that is designed to manage cryptographic keys and their metadata. An automated key-management system may be used to oversee, automate, and secure the key-management process. However, there are additional considerations when designing and operating such a system. Among these are controlling access to the system by authenticating the individuals requesting access and verifying their authorization to do so (see Sec. 8.1), creating and maintaining an inventory of keys and certificates to monitor when a key or certificate needs to be replaced and who is responsible for key and certificate replacement (see Sec. 8.2), assigning responsibilities and monitoring system activities (see Sec. 8.3), auditing the implementation and performance of the system and examining audit logs for irregularities (see Sec. 8.4), and ensuring system survivability (see Sec. 8.5).

4100

8.1. Access Control and Identity Authentication

4101 4102 4103 4104 4105

An access control system is needed to ensure that every key and metadata management function can only be initiated in response to a request by an authorized entity. When keymanagement functions are initiated by an entity, an access control system must ensure that the entity is authenticated and only performing the requested functions that are authorized for that entity and that all applicable constraints are satisfied.

4106 4107 4108 4109

The access-control system shall control access to and the initiation of all of its key and metadata management services and functions, including granting access and permission to initiate a requested service or function only after verifying the identity and authorization of the requesting entity to perform the requested service or function.

4110 4111 4112 4113 4114

Providing access control requires a means of identifying the entities accessing the keys. Commonly used methods include the use of two-factor authentication and digital signature certificates. These methods require identity proofing of the entities. [SP 800-63], [SP 800130], and [SP 800-152] provide further discussions and requirements for access control and identity authentication.

4115 4116 4117

All access to keys should be recorded in audit logs for periodic and emergency examination, including both successful and failed access attempts. See Sec. 8.4 for a discussion about auditing these logs.

4118

8.2. Inventory Management

4119 4120 4121 4122 4123 4124 4125

When using cryptographic mechanisms that employ keys, all long-term keys shall be inventoried. In the case of symmetric keys, this includes the keys used for the protection of information in transit and in storage. For asymmetric key pairs, this includes the key pairs owned by organizational entities (i.e., entities within the organization that are authorized to use the private key of the key pair). When certificates are issued for the public key of the key pair, records shall be maintained for those certificates. These records need to be maintained by an inventory management system. 129

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4126 4127 4128 4129 4130

Inventory management is concerned with establishing and maintaining records of the keys and/or certificates in use, assigning and tracking their owners or sponsors45 (e.g., who or what they are, where they are located, and how to contact them), monitoring key and certificate status (e.g., expiration date and whether a key is compromised), and reporting the status to the appropriate official for remedial action when required.

4131

8.2.1. Key Inventories

4132 4133 4134 4135 4136 4137 4138

A key inventory shall include information about each long-term key (e.g., all or part of the metadata associated with the key). Unless the inventory is also used for key backup or archiving, the inventory shall not include secret or private keys but shall include a reference to the key (e.g., a key identifier or pointer to the location of the key). The information in the inventory should indicate who/what owns or shares the key, the key type, the algorithm with which the key is to be used, the key length, how it is used (e.g., the application), and its expiration date.

4139 4140 4141 4142 4143 4144

Key inventories should be maintained in a central repository or network of mutually trusted repositories and operated in accordance with a Key-Inventory Policy. 46 If a key is compromised, the owners or sponsors associated with the compromised key need to be notified so that remedial actions can be taken, including revoking the key, analyzing the effects of the compromise, and replacing the key when appropriate. The information in the inventory can be used to identify who needs to be notified and how to contact them.

4145 4146 4147 4148 4149 4150

If an owner is no longer authorized to use a key (e.g., the owner is a human who left the organization or a device that was removed from the system), other entities need to be notified so that further interaction using that key is terminated. If the key is a symmetric key, the information in the inventory can be used to identify other entities that need to be notified and how to contact them. If the key is an asymmetric key and PKI certificates are used, notification is usually accomplished using CRLs.

4151 4152 4153 4154 4155 4156

The key needs to be replaced if its cryptoperiod expires or is about to expire and interactions between the entities using that key are to continue (i.e., using a replacement key). A keyinventory management system can be used to monitor cryptoperiods and alert the key owners or sponsors that keys are about to expire. The inventory management system can also be used to find keys for algorithms and key lengths that are no longer considered to be secure in order to arrange for algorithm and/or key replacement.

4157

8.2.2. Certificate Inventories

4158 4159 4160 4161

Certificates are used by communication servers (e.g., TLS, SSH) to provide web applications and services (e.g., government services, online banking, flight operations, mission-critical services within an organization), by devices (e.g., routers), and by client applications (e.g., browsers) used by the humans who use those communications and services. The certificates 45 See Sec. 2 for a discussion about owners and sponsors. 46 See [SP 800-57p2] for additional information.

130

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4162 4163

are used to establish identity, provide public keys to verify signatures on documents and the integrity of communicated information, and to establish keys to protect communications.

4164 4165 4166 4167 4168 4169 4170 4171

In many cases, certificates have been created and installed without recording the details associated with them (e.g., who or what device or process is associated with a certificate, what device or process has the private key, the location of the device or process, or the certificate’s validity period). As a result, significant outages occur when 1) the certificate expires and needs to be replaced before business operations can continue, or 2) the private key is compromised, and the certificate needs to be revoked and replaced before secure operations can be assured. To facilitate recovery operations and avoid outages in the case of expired certificates, a certificate shall be inventoried upon creation.

4172 4173 4174 4175 4176 4177 4178 4179

A certificate inventory includes the latest certificates for each entity and information about each certificate, including the identity of the certificate owner and contact information for the owner. The private keys associated with the public keys in the certificates shall not be included in the inventory unless the inventory is also used for key backup or archiving, and the backup or archiving of the private key is permitted (see Sec. 7.2.2.1 and 7.3.1). Certificate inventories should be maintained in a central repository or network of mutually trusted repositories and operated in accordance with a certificate policy. See [SP 800-57p2] for additional information.

4180 4181 4182 4183

A certificate inventory application shall be used to enter a certificate into the inventory, monitor certificate validity periods for proactive certificate replacement, detect the use of algorithms and key lengths that are no longer secure, respond to cryptographic incidents (e.g., CA compromise), and modify who should be contacted for certificate maintenance.

4184

8.3. Accountability

4185 4186

Accountability has two different aspects with respect to key management: responsibility and traceability.

4187 4188 4189 4190 4191

Each human involved with key management must be clearly informed about their keymanagement responsibilities and held accountable for fulfilling them. This includes the roles that people are assigned, the key-management responsibilities for those roles, and monitoring the performance of the individuals assigned to those roles. See [SP 800-130] for discussions of the different roles and responsibilities associated with key management.

4192 4193 4194 4195 4196 4197

Traceability involves identifying entities that are authorized to generate, access, destroy, or otherwise use keys; recording who or what actually performs these actions; and auditing the logs for security violations (see Sec. 8.4). Traceability can be an effective tool to help prevent key compromises and reduce the impacts of compromises when they are detected. Providing traceability for a system requires identifying the entities accessing the system and employing access-control mechanisms (see Sec. 8.1).

4198 4199 4200

Although it is preferred that no humans be able to view keys, as a minimum, any access to plaintext cryptographic keys shall be traceable to the entity accessing them, regardless of whether the entity is a human, device, application, or process. Access to ciphertext keys and

131

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4201 4202 4203 4204 4205 4206 4207

key shares should also be traceable to the accessing entities. For example, a sophisticated traceability system might be able to determine each entity that had control of any given key over its entire lifespan. This would include the entity that generated the key, the entity that used the key to cryptographically protect data, any other entity known to have accessed the key, and the entity that was responsible for destroying the key when it was no longer needed. Even though these other entities may never have actually accessed the key in its plaintext form, any actions they performed on or with the key should be traceable to them.

4208

Traceability provides three significant advantages:

4209 4210

1. It helps determine when a compromise could have occurred and what entities could have been involved.

4211 4212 4213 4214

2. It tends to discourge compromise attempts because individuals with access to the key know that their access to the key is known, and the developers of devices, applications, and processes that access the key know that access will be traced to these entities.

4215 4216 4217

3. When recovering from a detected key compromise, it is very useful to know where the key was used and what data or other keys were protected by the compromised key.

4218 4219 4220

Certain principles are useful when enforcing the traceability of cryptographic key use, although these principles might not be applicable to all systems or all key types. The principles include:

4221

•

Uniquely identifying keys

4222

•

Identifying other keys that are protected by a symmetric or private key

4223 4224 4225 4226

•

Logging (i.e., recording) any activity related to keys or the associated metadata, including their generation, access, modification, revocation, destruction, or any other access to them. Section 7.2.4 in [SP 800-152] lists appropriate information that shall be recorded for key management events (e.g., key generation and destruction).

4227

8.4. Audit

4228 4229

The auditing of activities associated with key management is required. Three types of audits should be performed on key-management systems:

4230 4231 4232 4233 4234 4235 4236 4237

1. Initial and periodic compliance audits should be conducted to determine that a keymanagement system is prepared to operate or continues to operate in compliance with its key management policy and practice requirements. This includes 1) an examination of the security plan and the procedures that are developed to support the plan to determine whether they support the policy (see [SP 800-57p2]) and 2) confirmation that roles and responsibilities are defined, all participants have been educated and understand their roles, systems are in place to maintain an accurate inventory of all keys, the processes used are appropriate for the applications and risks,

132

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4238 4239

access controls are properly implemented, and access is removed when personnel are reassigned.

4240 4241 4242 4243 4244

2. The protective mechanisms employed (e.g., access control mechanisms) should be periodically reassessed with respect to the level of security that they provide and are expected to provide in the future and whether the mechanisms correctly and effectively support the appropriate policies. New technological developments and attacks should be taken into consideration.

4245 4246 4247 4248 4249 4250 4251

3. On a more frequent basis, the actions of the entities that use, operate, and maintain the system should be reviewed to verify that they continue to follow established security procedures and have accessed only those keys and metadata for which they are authorized. This is normally accomplished by examining the logs created to record security-relevant events. Strong cryptographic systems can be compromised by lax and inappropriate actions. Highly unusual events should be noted and reviewed as possible indicators of attempted attacks on the system.

4252 4253

Audit reports shall be provided as specified in the key-management policy (e.g., to a System Authority).

4254

8.5. Key-Management System Survivability

4255 4256 4257 4258 4259 4260

A failure in a key-management system or its environment could hamper or prevent access to an organization’s stored information. Disaster recovery requires having procedures and a sufficient backup capability to recover from facility damage, utility service outages, communication and computation outages, hardware and software failures, and other failures that result in the corruption or loss of the stored key information or the key-management system itself.

4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274

[OMB 11-01] notes that encryption is an important tool for protecting the confidentiality of disclosure-sensitive information that is entrusted to an agency’s care but that the encryption of agency data also presents risks to the availability of information needed for mission performance. Agencies are reminded of the need to protect the continuity of their information technology operations and agency services when implementing encryption. The guidance specifically notes that without access to the cryptographic keys that are needed to decrypt information, organizations risk losing their access to that information. The guidance particularly stresses that agencies must address information availability and assurance requirements through appropriate data-recovery mechanisms, such as cryptographic key recovery. Consequently, it is prudent to retain backed up or archived copies of the keys necessary to decrypt stored enciphered information, including master keys, key-wrapping keys, and the related keying material necessary to decrypt encrypted information until there is no longer any requirement for access to the underlying plaintext information (see Sec. 8.5.2, Table 10, and Table 11).

133

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4275

8.5.1. Backed Up and Archived Key

4276 4277 4278 4279 4280 4281 4282

[OMB 11-01] focuses on the need to recover decryption keys to decrypt encrypted information (see Sec. 8.5). However, as the tables in Sec. 7.2.2.1 show, there are other operational keys that organizations may need to backup or archive (e.g., public signatureverification keys and authorization keys). Backed up or archived copies of keying material shall be stored in accordance with the provisions of Sec. 5 to protect the confidentiality of encrypted information and the integrity of source authentication, identity authentication, integrity authentication, and authorization processes.

4283

8.5.2. Key Recovery

4284 4285 4286 4287

Key recovery is the process of retrieving or reconstructing a key from key backups or archives in order to process cryptographically protected information (e.g., to decrypt encrypted information or verify a signature on signed information). There are several issues associated with key recovery, including:

4288

1. Which key information, if any, needs to be backed up or archived for later recovery?

4289

2. Where will backed up or archived key information be stored?

4290 4291

3. When will archiving be done (e.g., during key activation or at the end of a key’s cryptoperiod)?

4292

4. Who will be responsible for protecting the backed up or archived key information?

4293

5. What procedures need to be in place for storing and recovering the key information?

4294

6. Who can request a recovery of the key information and under what conditions?

4295

7. Who will be notified when a key recovery has taken place and under what conditions?

4296 4297

8. What audit or accounting functions need to be performed to ensure that the key information was only provided to authorized entities?

4298 4299

Key recovery itself does not result in the deletion of key information from backups or archives.

4300 4301 4302 4303 4304

The permissible use of a key after recovery may depend on its cryptoperiod (see Sec. 4.3.4 and 4.3.5). Whether a key should be recovered and used and from where it should be recovered depends on several factors, including its cryptoperiod, class (i.e., symmetric or asymmetric), use or purpose, and whether it has been compromised or suspected of being compromised.

4305

When a key has been backed up or archived, keys may be recovered and used as follows:

4306 4307 4308 4309

1. If the key is not known to be or suspected of being compromised: •

Secret (symmetric) key: The recovered key may be used for applying protection (e.g., for encryption) only if the key’s originator-usage period has not been exceeded. The

134

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4310 4311 4312 4313

recovered key should be revoked as soon as possible, thus ending its originator-usage period. If continued functionality is needed after revocation for applying protection, a new key shall be generated to replace the recovered key for applying cryptographic protection.

4314 4315 4316

The recovered key may be used to process protected data (e.g., used for decrypting ciphertext data) if the recipient-usage period of the key has not been exceeded or the key was recovered from archive storage.

4317

•

Private key of an asymmetric key pair:

4318 4319 4320 4321 4322 4323 4324

A recovered private signature key may be used for signature generation if the key’s cryptoperiod has not been exceeded. Recall that backing up a private signature key is discouraged in most cases (see Sec. 7.2.2.1), and archiving a private signature key is disallowed (see Sec. 7.3.1). A recovered private signature key should be revoked 47 as soon as possible. If continued functionality is needed after revocation, a new signature key pair shall be generated.

4325 4326

A recovered private key-transport key may be used to decrypt keys if the cryptoperiod has not been exceeded.

4327 4328 4329 4330

A recovered private key-agreement key may be used to establish new keys if the cryptoperiod has not been exceeded. A recovered private key-agreement key should be revoked 48 as soon as possible. If continued functionality is needed after revocation, a new key pair shall be generated.

4331 4332

A recovered private decapsulation key may be used to decapsulate keys if the cryptoperiod has not been exceeded.

4333

•

Public key of an asymmetric key pair:

4334 4335 4336 4337

Recovered public signature-verification keys, public key-transport keys, and public encapsulation keys may be used for their assigned purposes (i.e., signature verification, encryption, or encapsulation, respectively) if the cryptoperiod has not been exceeded.

4338 4339

A recovered public key-agreement key may be used if the cryptoperiod of the key has not been exceeded.

4340 4341 4342

2. If the key information has been compromised, the recovered key shall be revoked (see Sec. 8.5.4). The recovered key should only be used if the level of risk is acceptable, as determined by the user and/or the user’s organization.

4343

•

Secret symmetric key:

47 If the corresponding public key has been included in a public-key certificate, the revocation of the key pair can be accomplished by revoking the public key in the certificate. 48 If the corresponding public key has been included in a public-key certificate, the revocation of the key pair can be accomplished by revoking the public key in the certificate.

135

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4344 4345 4346

The recovered key shall not be used to apply protection (e.g., encryption). If continued functionality is needed to apply protection, a new key shall be generated.

4347 4348

The recovered key may be used to process protected data (e.g., used for decryption).

4349

•

Private key of an asymmetric key pair:

4350

A recovered private signature-key shall not be used.

4351 4352 4353

A recovered private key-transport key or private decapsulation key may be used for its assigned purpose (i.e., key decryption or decapsulation, respectively) if the risk of doing so is acceptable.

4354 4355

A recovered private key-agreement key shall not be used to establish new keys, although it may be used to reconstruct already established keys.

4356

•

Public key of an asymmetric key pair:

4357 4358

A recovered public signature-verification key may be used for signature verification.

4359 4360

A recovered public key-transport key or public encapsulation key shall not be used.

4361 4362

A recovered public key-agreement key shall not be used to establish new keys, although it may be used to reconstruct already established keys.

4363

8.5.3. System Redundancy/Contingency Planning

4364 4365 4366 4367 4368 4369 4370

Cryptography is a useful tool for preventing unauthorized access to data and/or resources, but when the mechanism fails, the use of cryptography can prevent access by valid entities to critical information and processes. For example, loss or corruption of the only copy of a decryption key can deny access to encrypted information. The continuity of an organization’s operations can depend heavily on contingency planning for key-management systems with a redundancy of critical logical processes and elements, including key management and cryptographic keys.

4371

8.5.3.1. General Principles

4372 4373 4374 4375 4376

Planning for recovery from system failures is an essential management function. Interruptions of critical infrastructure services should be anticipated, and a plan for maintaining the continuity of operations in support of an organization’s primary mission requirements shall be in place. With respect to key management, the following situations are typical of those for which planning is necessary:

4377

•

Lost key cards or tokens

4378

•

Forgotten authenticators (e.g., tokens or passwords) that control access to keys

136

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4379

•

The failure of key-input devices (e.g., readers, PIV cards)

4380 4381

•

The loss or corruption of the memory media on which keys and/or certificates are stored

4382

•

The compromise of keys

4383

•

Certificate termination without replacement certificates being installed

4384

•

The corruption of CRLs or CKLs

4385 4386

•

Hardware failure of key or certificate generation, registration, and/or distribution systems, subsystems, or components

4387 4388

•

Power loss that requires the re-initialization of key or certificate generation, registration, key-establishment systems, subsystems, or components

4389 4390

•

The corruption of the memory media necessary for key or certificate generation, registration, key-establishment systems, subsystems, or components

4391

•

The loss or corruption of key or certificate distribution records and/or audit logs

4392

•

The loss or corruption of the association of keys to the key owners

4393 4394

•

The unavailability of older software or hardware that is needed to access key information or process protected information

4395 4396 4397 4398 4399 4400 4401

While recovery discussions most commonly focus on the recovery of encrypted data and the restoration of encrypted communication capabilities, planning should also address 1) the restoration of access when cryptography is used in access control mechanisms without creating a temporary loss of access protections, 2) the restoration of critical processes when cryptography is used in authorization mechanisms without creating a temporary loss of authorization restrictions, and 3) the maintenance/restoration of integrity protection in digital signature and message authentication applications.

4402 4403 4404 4405

Contingency planning should include 1) providing a means and assigning responsibilities for rapidly recognizing and reporting critical failures; 2) assigning responsibilities and providing resources for bypassing or replacing failed systems, subsystems, and components; and 3) establishing detailed bypass and/or recovery procedures.

4406 4407 4408 4409 4410 4411 4412

Contingency planning includes a full range of integrated logistical support functions. Spare parts (e.g., copies of critical devices, software programs, manuals, data files) should be available (either acquired or arranged for) and pre-positioned or delivery-staged. Emergency maintenance, replacement, and/or bypass instructions should be prepared and disseminated to designated individuals and at an accessible and advertised access point. Designated individuals should be trained in their assigned recovery procedures, and all personnel should be trained in reporting and recovery procedures.

137

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4413

8.5.3.2. Cryptography and Key-Management-Specific Recovery Issues

4414 4415 4416 4417 4418 4419 4420 4421 4422 4423

A key recovery capability generally involves some redundancy or multiple copies of key information. If one copy of critical key information is lost or corrupted, another copy usually needs to be available to recover data and/or restore capabilities. However, the more copies of a key that exist and are distributed to different locations, the more susceptible the key is to compromise by penetration of the storage location or subversion of the custodian (e.g., user, service agent, or key production/distribution facility). In this sense, key confidentiality requirements conflict with continuity of operations requirements. Special care needs to be taken to safeguard all copies of key information, especially information about symmetric keys and private (asymmetric) keys. More details regarding contingency plans and planning requirements are provided in [SP 800-57p2].

4424

8.5.4. Compromise Recovery

4425 4426 4427 4428 4429 4430 4431 4432

When a secret or private key that is used to protect sensitive information or critical processes is disclosed to unauthorized entities, all of the information and/or processes protected by that key become immediately subject to disclosure, modification, subversion, and/or denial of service. All compromised keys shall be revoked; all affected keys shall be replaced, if needed; and, where sensitive or critical information or processes are affected, an immediate damage assessment should be conducted. Measures necessary to mitigate the consequences of a suspected unauthorized access to protected data or processes and to reduce the probability or frequency of future compromises should be undertaken.

4433 4434 4435 4436

Where secret (symmetric) keys or private (asymmetric) keys are used to protect only a single entity’s local information or communications between a single pair of entities, the compromise recovery process can be relatively simple and inexpensive. Damage assessment and mitigation measures are often local matters.

4437 4438 4439

However, when a key is shared by or affects a large number of entities, damage can be widespread, and recovery is both complex and expensive. Some examples of keys whose compromise might be particularly difficult or expensive to recover from include the following:

4440 4441

•

A CA’s private signature key, especially if it is used to sign a root certificate in a publickey infrastructure

4442

•

A symmetric key-wrapping key shared by a large number of entities

4443 4444

•

A key-derivation key/master key used in the derivation of keys by a large number of entities

4445

•

A symmetric data-encryption key used to encrypt data in a large, distributed database

4446

•

A symmetric key shared by a large number of communications network participants

4447

•

A key used to protect a large number of stored keys

4448 4449

In all of these cases, a large number of key owners and relying parties (e.g., all parties authorized to use the secret key of a symmetric-key algorithm or the public key of an

138

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4450 4451 4452 4453 4454 4455 4456

asymmetric-key algorithm) need to be immediately notified of the compromise. The inclusion of the key identifier on a CKL or the certificate serial number on a CRL to be published at a later date might not be sufficient. This means that a list of the most likely affected entities may need to be maintained, and a means for communicating the news of a compromise will be required. Particularly in the case of a compromised symmetric key, the news of a compromise and the replacement of keys should be sent only to the affected entities so as not to encourage others to exploit the situation.

4457 4458 4459 4460 4461 4462 4463

A secure path for replacing compromised keys is required. To permit the rapid restoration of service, an automated (e.g., over-the-air or network-based) replacement path is preferred (see Sec. 7.2.3). In some cases, however, there may be no practical alternative to manual distribution (e.g., the compromise of a root CA’s private key). A contingency distribution of alternative keys may help restore service rapidly in some circumstances (e.g., the compromise of a widely held symmetric key), but the possibility of a simultaneous compromise of operational and contingency keys would need to be considered.

4464 4465 4466

Damage assessment can be extraordinarily complex, particularly for the compromise and replacement of CA private keys, widely used key-transport or encapsulation keys, and keys that are used by many users of large, distributed databases.

139

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4467

References

4468 4469 4470 4471 4472

[CSWP15]

Barker W, Polk W, Souppaya M (2021) Getting Ready for Post-Quantum Cryptography: Exploring Challenges Associated with Adopting and Using Post-Quantum Cryptographic Algorithms. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity White Paper (CSWP) CSWP 15. https://doi.org/10.6028/NIST.CSWP.15

4473 4474 4475 4476

[DiCrescenzo]

Di Crescenzo G, Ferguson N, Impagliazzo R, Jakobsson M (1999) How to forget a secret. STACS 99: 16th Annual Symposium on Theoretical Aspects of Computer Science (Springer, Trier, Germany), pp 500-509. https://doi.org/10.1007/3-540-49116-3_47

4477 4478 4479 4480

[Grassl]

Grassl M, Langenberg B, Roetteler M, and Steinwandt R, (2016) Applying Grover’s algorithm to AES: quantum resource estimates, in Takagi T ed. PostQuantum Cryptography, Lect. Notes in Comput. Sci. vol. 9606, Springer, pp. 9– 43. Available at https://arxiv.org/abs/1512.04965

4481 4482 4483 4484

[FIPS 140-3]

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

4485 4486 4487 4488

[FIPS 180]

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

4489 4490 4491 4492

[FIPS 186-4]

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

4493 4494 4495 4496

[FIPS 186-5]

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

4497 4498 4499 4500

[FIPS 197]

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

4501 4502 4503 4504 4505

[FIPS 199]

National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) FIPS 199. https://doi.org/10.6028/NIST.FIPS.199

140

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4506 4507 4508 4509

[FIPS 201-3]

National Institute of Standards and Technology (2022) Personal Identity Verification (PIV) of Federal Employees and Contractors, (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) FIPS 201-3. https://doi.org/10.6028/NIST.FIPS.201-3

4510 4511 4512 4513 4514

[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, D.C.), Federal Information Processing Standards Publication (FIPS) FIPS 202. https://doi.org/10.6028/NIST.FIPS.202

4515 4516 4517 4518 4519

[FIPS 203]

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

4520 4521 4522 4523

[FIPS 204]

National Institute of Standards and Technology (2024. Module-Lattice-Based Digital Signature Standard. (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) FIPS 204. https://doi.org/10.6028/NIST.FIPS.204

4524 4525 4526 4527

[FIPS 205]

National Institute of Standards and Technology (2024) Stateless Hash-Based Digital Signature Standard. (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) FIPS 205. https://doi.org/10.6028/NIST.FIPS.205

4528 4529 4530 4531

[FPKI-KRP]

Federal Public Key Infrastructure Policy Authority (2017) Federal Public Key Infrastructure Key Recovery Policy, version 1.0. Available at https://www.idmanagement.gov/docs/archived/fpki-keyrecovery_20240205.pdf

4532 4533 4534 4535 4536

[IGD_B]

National Institute of Standards and Technology, Canadian Centre for Cyber Security (2024) Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program, [Amended]. Available at https://csrc.nist.gov/csrc/media/Projects/cryptographic-modulevalidation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

4537 4538 4539

[ISO/IEC 19790] ISO/IEC 19790, Information technology — Security techniques — Security requirements for cryptographic modules 2025. Available at https://www.iso.org/standard/82423.html

4540 4541 4542 4543

[ITLBulletin]

Burr WE, Hash JS (2002) Techniques for System and Data Recovery. (National Institute of Standards and Technology, Gaithersburg, MD), ITL Bulletin, April 2002. Available at https://csrc.nist.gov/files/pubs/shared/itlb/itlbul200204.pdf

4544 4545

[Jones]

Jones NC, Van Meter R, Fowler AG, McMahon PL, Kim J, Ladd TD, Yamamoto Y (2012) Layered Architecture for Quantum Computing. American Physical

141

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

4546 4547

Recommendation for Key Management Part 1 — General

Society, Phys. Rev. X 2, 031007. Available https://journals.aps.org/prx/abstract/10.1103/PhysRevX.2.031007

at

4548 4549 4550

[Mariantoni]

Mariantoni M, (2014) Building a Superconducting Quantum Computer, Invited Talk PQCrypto 2014, Waterloo, Canada. Available at https://youtu.be/wWHAs--HA1c

4551 4552 4553 4554

[NIST IR 7977]

Cryptographic Technology Group (2016) NIST Cryptographic Standards and Guidelines Development Process. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Internal Report (IR) NIST IR 7977. https://doi.org/10.6028/NIST.IR.7977

4555 4556 4557 4558 4559

[NIST PQC eval] National Institute of Standards and Technology (2016) NIST Submission Requirements and Evaluation Criteria for the Post-Quantum Cryptography Standardization Process. Available at https://csrc.nist.gov/CSRC/media/Projects/Post-QuantumCryptography/documents/call-for-proposals-final-dec-2016.pdf

4560 4561 4562 4563 4564

[OMB 11-01]

Office of Management and Budget (2001) OMB Guidance to Federal Agencies on Data Availability and Encryption. (National Institute of Standards and Technology, Gaithersburg, MD), [November 26, 2001]. Available at https://csrc.nist.gov/csrc/media/projects/block-ciphertechniques/documents/ombencryption-guidance.pdf

4565 4566 4567 4568 4569

[RFC 2560]

Santesson S, Myers M, Ankney R, Malpani A, Galperin S, Adams C (2013) X.509 Internet Public Key Infrastructure, Online Certificate Status Protocol – OCSP. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 6960. Available at https://datatracker.ietf.org/doc/html/rfc6960

4570 4571 4572 4573

[RFC 3647]

Chokhani S, Ford W, Sabett R, Merrill C, Wu S (2003) Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 3647. https://doi.org/10.17487/RFC3647

4574 4575 4576

[RFC 8032]

Josefsson S, Liusvaara I (2017) Edwards-Curve Digital Signature Algorithm (EdDSA). (Internet Research Task Force (IRTF)), IRTF Request for Comments (RFC) 8032. https://doi.org/10.17487/RFC8032

4577 4578 4579 4580 4581

[SP 800-37]

Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-37r2. https://doi.org/10.6028/NIST.SP.800-37r2

4582 4583 4584 4585

[SP 800-38]

Dworkin M (2001) Recommendation for Block Cipher Modes of Operation. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-38. Available at https://csrc.nist.gov/projects/block-cipher-techniques/bcm/current-modes

142

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4586 4587 4588 4589

[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) NIST SP 800-38A. https://doi.org/10.6028/NIST.SP.800-38A

4590 4591 4592 4593 4594

[SP 800-38B]

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

4595 4596 4597 4598 4599

[SP 800-38C]

Dworkin MJ (2004) Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-38C, Includes updates as of July 20, 2007. https://doi.org/10.6028/NIST.SP.800-38C

4600 4601 4602 4603

[SP 800-38D]

Dworkin MJ (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 80038D. https://doi.org/10.6028/NIST.SP.800-38D

4604 4605 4606 4607

[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) NIST SP 800-38F. https://doi.org/10.6028/NIST.SP.800-38F

4608 4609 4610 4611 4612

[SP 800-52]

Polk T, McKay KA, Chokhani S (2019) Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-52r2. https://doi.org/10.6028/NIST.SP.800-52r2

4613 4614 4615 4616 4617

[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) NIST SP 800-56Ar3. https://doi.org/10.6028/NIST.SP.800-56Ar3

4618 4619 4620 4621 4622

[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) NIST SP 80056Br2. https://doi.org/10.6028/NIST.SP.800-56Br2

4623 4624

[SP 800-56C]

Barker EB, Chen L, Davis R (2018) Recommendation for Key-Derivation Methods in Key-Establishment Schemes. (National Institute of Standards

143

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

4625 4626

Recommendation for Key Management Part 1 — General

and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-56Cr1. Withdrawn. https://doi.org/10.6028/NIST.SP.800-56Cr1

4627 4628 4629 4630

[SP 800-57p2]

Barker EB, Barker WC (2019) Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-57pt2r1. https://doi.org/10.6028/NIST.SP.800-57pt2r1

4631 4632 4633 4634

[SP 800-57p3]

Barker EB, Dang QH (2015) Recommendation for Key Management, Part 3: Application-Specific Key Management Guidance. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-57pt3r1. https://doi.org/10.6028/NIST.SP.800-57pt3r1

4635 4636 4637 4638 4639 4640 4641 4642 4643 4644

[SP 800-63]

Temoshok D, Madruga DP, Choong YY, Galluzzo R, Gupta S, LaSalle C, Lefkovitz N, Regenscheid A (2024) Digital Identity Guidelines. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63-4 2pd. https://doi.org/10.6028/NIST.SP.80063-4.2pd Temoshok D, Abruzzi C, Choong YY, Fenton JL, Galluzzo R, LaSalle C, Lefkovitz NB, Regenscheid A (2024) Digital Identity Guidelines: Enrollment and Identity Proofing. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63A-4 2pd. https://doi.org/10.6028/NIST.SP.800-63A-4.2pd

4645 4646 4647 4648

[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) NIST SP 80067r2. Withdrawn. https://doi.org/10.6028/NIST.SP.800-67r2

4649 4650 4651 4652 4653

[SP 800-88]

Chandramouli R,,Hibbard E (2025) Guidelines for Media Sanitization. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-88r2. https://csrc.nist.gov/pubs/sp/800/88/r2/final#:~:text=https%3A//doi.org/1 0.6028/NIST.SP.800%2D88r2

4654 4655 4656 4657

[SP 800-89]

Barker EB (2006) Recommendation for Obtaining Assurances for Digital Signature Applications. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-89. https://doi.org/10.6028/NIST.SP.800-89

4658 4659 4660 4661

[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) NIST SP 800-90Ar1. https://doi.org/10.6028/NIST.SP.800-90Ar1

4662 4663 4664

[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

[SP 800-63A]

144

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

4665 4666

Recommendation for Key Management Part 1 — General

Special Publication (SP) https://doi.org/10.6028/NIST.SP.800-90B

NIST

SP

800-90B.

4667 4668 4669 4670 4671

[SP 800-90C]

Barker EB, Kelsey JM, McKay K, Roginsky A, 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

4672 4673 4674 4675

[SP 800-108]

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

4676 4677 4678 4679

[SP 800-130]

Barker EB, Smid ME, Branstad DK, Chokhani S (2013) A Framework for Designing Cryptographic Key Management Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-130. https://doi.org/10.6028/NIST.SP.800-130

4680 4681 4682 4683

[SP 800-131A]

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

4684 4685 4686 4687

[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) NIST SP 800-132. https://doi.org/10.6028/NIST.SP.800-132

4688 4689 4690 4691

[SP 800-133]

Barker EB, Roginsky AL (2019) Recommendation for Cryptographic Key Generation. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-133r1. Withdrawn. https://doi.org/10.6028/NIST.SP.800-133r1

4692 4693 4694 4695

[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) NIST SP 800-135r1. https://doi.org/10.6028/NIST.SP.800-135r1

4696 4697 4698 4699 4700 4701 4702 4703

[SP 800-140]

Schaeffer K (2020) FIPS 140-3 Derived Test Requirements (DTR): CMVP Validation Authority Updates to ISO/IEC 24759. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-140. https://doi.org/10.6028/NIST.SP.800-140 Barker EB, Branstad DK, Smid ME (2015) A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-152. https://doi.org/10.6028/NIST.SP.800-152

[SP 800-152]

145

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4704 4705 4706 4707

[SP 800-175B]

Barker EB (2020) Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-175Br1. https://doi.org/10.6028/NIST.SP.800-175Br1

4708 4709 4710 4711

[SP 800-185]

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

4712 4713 4714 4715

[SP 800-208]

Cooper D, Apon D, Dang Q, Davidson M, Dworkin M, Miller C (2020) Recommendation for Stateful-Hash-Based Signature Schemes. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-208. https://doi.org/10.6028/NIST.SP.800-208

4716 4717 4718 4719 4720

[SP 800-224]

Sönmez Turan M, Brandão (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

4721 4722 4723 4724

[SP 800-227]

Alagic G, Barker E, 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

4725 4726 4727 4728 4729

[SP 800-232]

Sönmez Turan M, McKay K, Chang D, Kang J, Kelsey J (2025) Ascon-Based Lightweight Cryptography Standards for Constrained Devices: Authenticated Encryption, Hash, and Extendable Output Functions. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-232. https://doi.org/10.6028/NIST.SP.800-232

4730 4731

[X995]

American National Standard (ANS) X9.31-2022, Trusted Timestamp Management and Security.

4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743

[ISO/IEC18014] Timestamping: ISO/IEC 18014-1:2008 Information technology – Security techniques – Timestamping services – Part 1: Framework ISO/IEC 18014-2:2021 Information security – Time-stamping services – Part 2: Mechanisms producing independent tokens ISO/IEC 18014-3:2009 Information technology – Security techniques – Timestamping services – Part 3: Mechanisms producing linked tokens ISO/IEC 18014-4:2015 Information technology – Security techniques – Timestamping services – Part 4: Traceability of time sources [Zalka] Zalka C (1999) Grover’s quantum searching algorithm is optimal, American Physical Society, Phys. Rev. A 60, 2746. Available at https://journals.aps.org/pra/abstract/10.1103/PhysRevA.60.2746

146

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4744 4745

Appendix A. Cryptographic and Non-Cryptographic Integrity and Source Authentication Mechanisms

4746 4747 4748 4749 4750 4751 4752 4753 4754

Integrity and source authentication services are particularly important in protocols that include key management. When integrity or source-authentication services are discussed in this recommendation, the use of “strong” cryptographic integrity or source-authentication mechanisms is assumed. Secure communications and key management are typically provided using a communication protocol that offers certain services, such as integrity protection or a “reliable” transport service. 49 However, the integrity protection or reliable transport services of communication protocols are not necessarily adequate for cryptographic applications, particularly for key management, and there might be confusion about the meaning of terms such as “integrity.”

4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770

All communication channels have some noise (i.e., unintentional errors inserted by the transmission media), and other factors (e.g., network congestion) can cause network packets 50 to be lost. Therefore, integrity protection and reliable transport services for communication protocols are designed to function over a channel with certain worst-case noise characteristics. entity that detects damaged packets (i.e., packets that contain bit errors) or lost packets Transmission bit errors are typically detected using 1) a noncryptographic checksum 51 to detect transmission errors in a packet and 2) a packet counter to detect lost packets. A receiving may ask the sender to retransmit them. Non-cryptographic checksums are generally effective at detecting transmission noise. For example, the common CRC-32 checksum algorithm used in local-area network applications detects all error bursts with a span of less than 32 bits and detects longer random bursts with a 2−32 failure probability. However, the non-cryptographic CRC-32 checksum does not detect the swapping of 32-bit message words, and specific errors in particular message bits cause predictable changes in the CRC-32 checksum. The sophisticated attacker can take advantage of this to create altered messages that pass the CRC-32 integrity checks, even (in some cases) when the message is encrypted.

4771 4772 4773 4774

Forward error-correcting codes are a subset of non-cryptographic checksums that can be used to correct a limited number of errors without retransmission. These codes may be used as checksums, depending on the application and noise properties of the communication channel.

4775 4776 4777 4778 4779

However, cryptographic integrity-authentication mechanisms (e.g., MACs, digital signatures) protect against an active, intelligent attacker who might attempt to disguise an attack as noise. Typically, the bits altered by the attacker are not random but target system properties and vulnerabilities. Cryptographic integrity-authentication mechanisms are effective at detecting random noise events, but they also detect more systematic deliberate attacks. 49 This means transmitting information within a network using protocols that provide assurances that the information is received correctly. 50 A network packet is a formatted unit of data that is used to send messages across a network. Messages may be divided into multiple

packets for transmission efficiency. A checksum is an algorithm that uses the bits in the transmission to create a checksum value, which is normally sent in the transmission. The receiver re-computes the checksum value using the bits in the received transmission and compares the received checksum value with the computed value to determine whether the transmission was correctly received. A non-cryptographic checksum algorithm uses a wellknown algorithm without secret information (i.e., without a cryptographic key). 51

147

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792

Cryptographic hash functions, such as SHA-256, are designed to make every bit of the hash value a complex, nonlinear function of every bit of the message text and to make it impractical to find two messages that hash to the same value. On average, it is necessary to perform 2128 SHA-256 hash operations to find two messages that hash to the same value, and it is much harder to find another message whose SHA-256 hash is the same value as the hash of any given message. Cryptographic MAC algorithms employ hash functions or symmetric encryption algorithms and keys to authenticate the source of a message and to protect its integrity (i.e., detect errors). Digital signatures use public-key algorithms and hash functions or XOFs to provide both integrity and source-authentication services. Compared to noncryptographic integrity or source-authentication mechanisms, these cryptographic services are usually computationally more expensive. This seems to be unavoidable, since cryptographic protections must also resist deliberate attacks by knowledgeable adversaries with substantial resources.

4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808

Cryptographic and non-cryptographic integrity-authentication mechanisms may be used together. For example, in the TLS protocol (see [SP 800-52]), a client and a server can authenticate each other’s identity, establish a shared “master key,” and transfer encrypted payload data. Every step in the entire TLS protocol run is protected by cryptographic integrity and source-authentication mechanisms, and the payload is usually encrypted. Like most cryptographic protocols, TLS will (with a given probability) detect any attack or noise event that alters any part of the protocol run. However, TLS has no error-recovery protocol. If an error is detected, the protocol run is simply terminated. Starting a new TLS protocol run is quite expensive. Therefore, TLS requires a “reliable” transport service, typically the internet Transport Control Protocol (TCP), to handle and recover from ordinary network transmission errors. TLS will detect errors caused by an attack or noise event but has no mechanism to recover from them. TCP will generally detect such errors on a packet-by-packet basis and recover from them by retransmitting individual packets before delivering the data to TLS. Both TLS and TCP have integrity-authentication mechanisms, but a sophisticated attacker could easily fool the weaker non-cryptographic checksums of TCP. However, because of the cryptographic integrity-authentication mechanism provided in TLS, the attack is thwarted.

4809 4810 4811 4812 4813 4814 4815 4816 4817

There are some interactions between cryptographic and non-cryptographic integrity or errorcorrection mechanisms that users and protocol designers must consider. For example, many encryption modes expand ciphertext errors, and a single bit error in the ciphertext can change an entire block or more of the resulting plaintext. If forward error correction 52 (e.g., using a MAC algorithm, such as HMAC) is applied before encryption, and errors are inserted in the ciphertext during transmission, the error expansion during the decryption might “overwhelm” the error-correction mechanism, making the errors uncorrectable. Therefore, it is preferable to apply the forward error-correction mechanism after the encryption process (e.g., compute a MAC on the encrypted data rather than computing a MAC on the plaintext

Forward error correction is a technique used for controlling errors in data transmissions. The sender encodes the message in a redundant way by using an error-detection code. The redundancy allows the receiver to detect a limited number of errors that may occur anywhere in the message and, often, to correct these errors without re-transmission.

52

148

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4818 4819

data and then performing encryption). This will allow the receiving entity’s system to correct errors before the ciphertext is decrypted, resulting in “correct” plaintext.

4820 4821 4822 4823 4824 4825 4826 4827

Interactions between cryptographic and non-cryptographic mechanisms can also result in security vulnerabilities. One classic way this occurs is with protocols that use stream ciphers53 with non-cryptographic checksums (e.g., CRC-32) that are computed over the plaintext data and that acknowledge good packets. An attacker can copy the encrypted packet, selectively modify individual ciphertext bits, selectively change bits in the CRC, and then send the packet. Using the protocol’s acknowledgement mechanism, the attacker can determine when the CRC is correct and, therefore, determine certain bits of the underlying plaintext. At least one widely used wireless encryption protocol has been broken with such an attack.

53 Stream ciphers encrypt and decrypt one element (e.g., bit or byte) at a time. There are no approved algorithms specifically designated as

stream ciphers. However, some of the cryptographic modes defined in [SP 800-38] can be used with a symmetric block cipher algorithm, such as AES, to perform the function of a stream cipher.

149

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4828

Appendix B. Key Recovery

4829

B.1. General Discussion

4830 4831 4832 4833 4834 4835 4836 4837 4838

Federal agencies have a responsibility to protect the information contained in, processed by, and transmitted between their information technology systems. Cryptographic techniques are often used as part of this process. These techniques are used to provide confidentiality, integrity authentication, identity authentication, source authentication, non-repudiation, and/or access control. Policies shall be established to address the protection and continued accessibility of cryptographically protected information, and procedures shall be in place to ensure that the information remains viable during its lifetime. When cryptographic keying material is used to protect the information, this same keying material may need to be available to remove (e.g., decrypt) or verify those protections (e.g., verify the MAC).

4839 4840

In many cases, the keying material used for cryptographic processes might not be readily available. This might be the case for several reasons, including:

4841 4842

1. The cryptoperiod of the key has expired, and the keying material is no longer in operational storage.

4843 4844

2. The keying material has been corrupted (e.g., the system has crashed, or a virus has modified the saved keying material in operational storage).

4845 4846

3. The key’s owner is not available, and the owner’s organization needs to obtain the plaintext information.

4847 4848 4849 4850 4851 4852 4853 4854 4855 4856

In order to have this keying material available when required, the keying material needs to be saved somewhere or be constructible (e.g., derivable) from other available keying material. The process of reacquiring the keying material is called key recovery. Key recovery is often used as one method of information recovery when the plaintext information needs to be recovered from encrypted information. However, keying material or other related information may need to be recovered for other reasons, such as the corruption of keying material in normal operational storage (e.g., for the verification of MACs for archived documents; see Sec. 7.2.1). Key recovery may also be appropriate for situations in which it is easier or faster to recover the keying material than it is to generate and distribute new keying material.

4857 4858 4859 4860 4861 4862

However, there are applications that may not need to save the keying material for an extended time because of other procedures to recover an operational capability when the keying material or the information protected by the keying material becomes inaccessible. Applications of this type could include telecommunications, where the transmitted information could be resent or applications that could quickly derive or acquire new keying material for distribution.

4863 4864 4865 4866

It is the responsibility of an organization to determine whether the recovery of keying material is required for their application. The decision for having a key-recovery capability should be made on a case-by-case basis, and this decision should be reflected in the KeyManagement Policy and the Key-Management Practices Statement (see [SP 800-57p2]). If the 150

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4867 4868 4869 4870 4871

decision is made to provide key recovery, the appropriate method of key recovery should be selected, designed, and implemented based on the type of keying material to be recovered. An appropriate entity needs to be selected to maintain the backup or archive database and manage the key-recovery process. If the decision is made to provide key recovery, all information associated with that key (e.g., metadata) shall also be recoverable.

4872

B.1.1. Recovery From Stored Keying Material

4873 4874 4875 4876 4877 4878 4879

The primary purpose of backing up or archiving keys and other key information is to be able to recover them when they are not otherwise available. For example, encrypted information cannot be transformed back into plaintext information if the decryption key is lost or modified; the integrity of data cannot be authenticated if the key used to verify the integrity of that data is not available. The key-recovery process retrieves the keying material from backup or archive storage and places it in a device, module, or other immediately accessible storage, often with the assistance of some human (see Sec. 7.3.1).

4880

B.1.2. Recovery by Reconstruction of Keying Material

4881 4882 4883 4884 4885

Some keying material may be recovered by reconstructing or re-deriving the keying material from other available keying material — that is, the “base” keying material (e.g., a keyderivation key for a key-derivation method or a seed). The base keying material shall be available in normal operational storage (see Sec. 7.2.1), backup storage (see Sec. 7.2.2.1), or archive storage (see Sec. 7.3.1).

4886

B.1.3. Conditions Under Which Keying Material Needs to be Recoverable

4887 4888

The decision to back up or archive keying material for possible key recovery should be made on a case-by-case basis and should be based on the list provided in Sec. 7.2.2.2.

4889 4890

When the key-recovery operation is requested by the key’s owner, the following actions shall be taken:

4891 4892 4893 4894

1. If a lost key may have been compromised, then the key shall be replaced as soon as possible after recovery to limit the exposure of the recovered key and the data it protects (see Sec. 7.2.3.1). This could include reapplying the protection on the protected data using a new key.

4895 4896

2. If the key becomes inaccessible or has been modified but compromise is not suspected, then the key may be recovered and used, as discussed in Sec. 8.5.2.

4897 4898 4899

Appendices B.2 through B.10 provide guidelines for determining whether a key-recovery capability is needed as well as other information that may be associated with the keys (e.g., the metadata associated with the key).

151

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4900

B.1.4. Key-Recovery Systems

4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911

Key recovery is a broad term that may be applied to several different techniques for recovering a cryptographic key and information associated with that key (e.g., the key’s metadata). The information required to recover a key may be different for each application or each key-recovery technique. The term “key-recovery information” (KRI) refers to the aggregate of key information that is needed to recover or verify cryptographically protected data. Information that may be considered KRI includes the keying material to be recovered or sufficient information to reconstruct the keying material, other associated key information, the time when the key was created, the identifier associated with the owner of the key (i.e., the individual, application, or organization that created the key or owns the data protected by that key), and any conditions that must be met by a requestor to be able to recover the keying material.

4912 4913 4914 4915 4916 4917

When an organization determines that key recovery is required for all or part of its keying material, a secure key-recovery system (KRS) needs to be established in accordance with a well-defined key recovery policy (see Appendix B.1.5). The KRS shall support the key recovery policy and consists of the techniques and facilities for saving and recovering the keying material, the procedures for administering the system, and the personnel associated with the system.

4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929

When key recovery is determined to be necessary, the KRI may be stored either within an organization (e.g., in backup or archive storage) or at a remote site by a trusted entity. There are many acceptable methods for enabling key recovery. A KRS 1) could be established using a safe to store keying material; 2) might use a single computer that provides the initial protection of the plaintext data, storage for the associated keying material, and recovery of that keying material; 3) may include a network of computers with a central key-recovery center; or 4) could be designed using other configurations. Since a KRS provides a means for recovering cryptographic keys, a risk assessment should be performed to ensure that the KRS adequately protects the organization’s information and reliably provides the KRI when required. It is the responsibility of the organization that needs to provide key recovery to ensure that the key-recovery policy, key-recovery methodology, and KRS adequately protect the KRI.

4930

A KRS used by the Federal Government shall:

4931 4932

1. Generate or provide sufficient KRI to allow for the recovery or verification of protected information

4933

2. Ensure the validity of the saved key and other KRI

4934 4935

3. Ensure that the KRI is stored with persistence and availability that is commensurate with that of the corresponding cryptographically protected data

4936

4. Use cryptographic modules that are compliant with [FIPS 140-3]

4937

5. Use approved algorithms when cryptography is used

152

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

4938 4939

6. Use algorithms and key lengths that provide security strengths commensurate with the sensitivity of the information associated with the KRI

4940

7. Be designed to enforce the key recovery policy (see Appendix B.1.5)

4941 4942 4943

8. Protect the KRI against unauthorized disclosure or destruction, verify the source of requests, and ensure that only requested and authorized information is provided to the requestor

4944

9. Protect the KRI from modification

4945 4946 4947 4948

10. Have the capability to provide an audit trail that shall not contain the keys that are recovered or any passwords that may be used by the system and that should include the identification of the event being audited, the time of the event, the identifier associated with the entity causing the event, and the success or failure of the event

4949 4950

11. Limit access to the KRI, the audit trail, and authentication data to authorized individuals

4951

12. Prohibit modification of the audit trail

4952

B.1.5. Key-Recovery Policy

4953 4954 4955 4956 4957 4958 4959

For each system, application, and cryptographic technique used, a determination must be made about whether the keying material needs to be saved for later recovery to allow for subsequent decryption or verification of the information protected by the keying material. An organization that determines that key recovery is required for some or all of its keying material should develop a key- recovery policy that addresses the protection and continued accessibility of that information 54 (see [FPKI-KRP]). The policy should answer the following questions (at a minimum):

4960 4961 4962 4963

1. What keying material needs to be saved for a given application? For example, keys and IVs used for the decryption of stored information may need to be saved. Keys used for the authentication of stored or transmitted information may also need to be saved.

4964 4965 4966 4967 4968

2. How and where will the keying material be saved? For example, the keying material could be stored in a safe by the individual who initiates the protection of the data (e.g., the encrypted data) or automatically saved when the protected data is transmitted, received, or stored. The keying material could be saved locally or at some remote site.

4969 4970 4971

3. Who will be responsible for protecting the KRI? For example, each individual, organization, or sub-organization could be responsible for their own keying material, or an external organization could perform this function.

4972 4973

4. Who is authorized to receive the KRI upon request and under what conditions? For example, the individual who protected the information (i.e., used and stored the KRI) 54 In the case of a PKI, an organization’s key-recovery policy may be included in its PKI Certificate Policy.

153

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

4974 4975 4976

Recommendation for Key Management Part 1 — General

or the organization to which the individual is assigned could recover the keying material. Legal requirements may need to be considered. An organization could request the information when the individual who stored the KRI is not available.

4977

5. Under what conditions can the policy be modified and by whom?

4978 4979 4980 4981 4982 4983

6. What audit capabilities and procedures will be included in the KRS? The policy shall identify the events to be audited. Auditable events might include KRI requests and their associated responses; who made a request and when; the startup and shutdown of audit functions; the operations performed to read, modify, or destroy the audit data; requests to access entity authentication data; and the uses of authentication mechanisms.

4984 4985

7. How will the KRS deal with aged keying material whose security strength has been reduced below an acceptable level?

4986 4987 4988 4989 4990

8. Who will be notified when keying material is recovered and under what conditions? For example, the individual who encrypted data and stored the KRI could be notified when the organization recovers the decryption key because the person is absent, but the individual might not be notified when the organization is monitoring the activities of that individual.

4991 4992

9. What procedures need to be followed when the KRS or some portion of the data within the KRS is compromised?

4993

B.2. Digital Signature Key Pair

4994 4995 4996 4997

The private key of a digital signature key pair (i.e., the private signature key) is used by the owner of the key pair to apply digital signatures to information. The corresponding public key (i.e., the public signature-verification key) is used by relying entities to verify the digital signature.

4998

B.2.1. Private Signature Key

4999 5000 5001 5002 5003 5004 5005

In general, a private signature key shall not be archived (see Table 12). Key backup is not usually desirable for the private key of a signing key pair since non-repudiation of the signature comes into question. However, exceptions may exist. For example, replacing the private signature key and having its corresponding public signature-verification key distributed in a timely manner in accordance with Sec. 7.1.5.1 may not be possible under some circumstances, so recovering the private signature key from backup storage may be justified. This may be the case, for example, for the private signature key of a CA.

5006 5007 5008 5009

If backup is considered for the private signature key, an assessment should be made about its importance and the time needed to recover the key as opposed to the time needed to generate a new key pair and certify and distribute a new public signature-verification key. If a private signature key is backed up, the private signature key shall be recovered using a

154

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5010 5011

highly secure method. Depending on circumstances, the key should be recovered for immediate use only and shall then be replaced as soon after the recovery process as possible.

5012 5013 5014 5015

Instead of backing up the private signature key, a second private signature key and corresponding public key could be generated and the public signature-verification key distributed in accordance with Sec. 7.1.5.1 for use if the primary private signature key becomes unavailable.

5016

B.2.2. Public Signature-Verification Key

5017 5018 5019 5020 5021 5022 5023

It is appropriate to back up or archive a public signature-verification key for as long as required to verify the information signed by the corresponding private signature key. In the case of a public key that has been certified (e.g., by a CA), saving the public-key certificate would be an appropriate form of storing the public key. Backup or archive storage may be provided by the infrastructure (e.g., by a certificate repository). The public key should be stored in backup storage until the end of the private key’s cryptoperiod and should be stored in archive storage as long as required for the verification of signed data.

5024

B.3. Authentication Keys

5025

Authentication keys are used to provide assurance of the integrity and source of information.

5026

B.3.1. Symmetric Authentication Key

5027 5028

A symmetric authentication key is used to provide assurance of the integrity and source of information. A symmetric authentication key can be used:

5029 5030 5031

1. By an originator to create a MAC that can be verified to determine the integrity and possibly the source of the authenticated information. The authenticated information and its MAC could then be stored for later retrieval or transmitted to another entity.

5032 5033 5034 5035 5036

The symmetric authentication key need not be backed up or archived if the originator can establish a new authentication key prior to computing the MAC, making the key available to any entity that would need to verify the information that is authenticated using this new key. If a new authentication key cannot be established in a timely manner, then the authentication key should be backed up or archived.

5037 5038 5039 5040

2. By a receiving entity immediately upon receipt of an authenticated message to determine the integrity of the received information and the source of that information. The received MAC and the associated authenticated information may or may not be subsequently stored.

5041 5042 5043 5044 5045

The symmetric authentication key need not be backed up or archived if the authentication key can be securely provided to the recipient with assurance of the identity of the sending entity. Alternatively, establishing a new symmetric authentication key rather than reusing the “lost” key is also acceptable. However, a new MAC would need to be computed on the information using the new 155

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5046 5047

authentication key. If neither alternative is acceptable, the symmetric authentication key should be backed up.

5048 5049 5050

If the MAC and the successfully authenticated information are subsequently stored, then the symmetric authentication key should be backed up or archived for as long as the integrity and source of the information needs to be determined.

5051 5052

3. By an entity that retrieves the authenticated information and the MAC from storage to determine the integrity of the stored information.

5053 5054

The symmetric authentication key should be backed up or archived for as long as the integrity and source of the information needs to be determined.

5055 5056 5057 5058 5059

The symmetric authentication key may be stored in backup storage for the cryptoperiod of the key and in archive storage until no longer required. If the authentication key is recovered by reconstruction, the “base” key (e.g., the master/key-derivation key for a key-derivation method or a seed) may be stored in normal operational storage or backup storage for the cryptoperiod of the base key and in archive storage until no longer required.

5060

B.3.2. Authentication (Asymmetric) Key Pair

5061 5062 5063 5064 5065

A public authentication key is used by a receiving entity to obtain assurance of the identity of the originating entity (i.e., the owner of the key pair). The corresponding private authentication key is used by the originating entity to provide this assurance to a receiving entity by computing a digital signature on information. This key pair may not provide support for non-repudiation.

5066

B.3.2.1. Private Authentication Key

5067 5068 5069 5070 5071 5072

A private authentication key is used to establish the identity of an entity (i.e., the owner of the key pair) who is participating in an authenticated communication session. The private authentication key need not be backed up if a new key pair can be generated and distributed in a timely manner in accordance with Sec. 7.1.5.1. However, if a new key pair cannot be generated quickly, the private key should be stored in backup storage during the cryptoperiod of the private key. The private key shall not be stored in archive storage.

5073

B.3.2.2. Public Authentication Keys

5074 5075 5076

It is appropriate to store a public authentication key in either backup or archive storage for as long as required to verify the identity of the owner of the key pair that is participating in an authenticated communication session.

5077 5078 5079 5080 5081

In the case of a public authentication key that has been certified (e.g., by a CA), saving the public-key certificate would be an appropriate form of storing the public key; backup or archive storage may be provided by the infrastructure (e.g., by a certificate repository). The public key may be stored in backup storage until the end of the private authentication key’s cryptoperiod and may be stored in archive storage as long as required. 156

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5082

B.4. Random Number Generation Key

5083 5084

A key used for random bit generation shall not be backed up or archived. If this key is lost or modified, it shall be replaced with a new key.

5085

B.5. Key-Derivation/Master Key

5086 5087

A symmetric key-derivation/master key is normally used to derive one or more keys or other keying material. It shall not be used for any other purpose.

5088 5089

The determination as to whether a symmetric key-derivation/master key needs to be backed up or archived depends on several factors:

5090 5091 5092 5093 5094

1. How easy is it to establish a new symmetric key-derivation/master key? If the key is distributed manually (e.g., in smart cards or in hard copy by receipted mail), the key should be backed up or archived. If a new key can be easily and quickly established using automated key-establishment protocols, then the backup or archiving of the key may not be necessary or desirable, depending on the application.

5095 5096 5097 5098 5099 5100 5101 5102

2. Are the derived keys recoverable without the use of the symmetric keyderivation/master key? If the derived keys do not need to be backed up or archived (e.g., because of their use) or recovery of the derived keys does not depend on reconstruction from the key-derivation/master key (e.g., the derived keys are stored in an encrypted form), then the backup or archiving of the key may not be desirable. If the derived keys need to be backed up or archived and the method of key recovery requires a reconstruction of the derived key from the key-derivation/master key, then the key-derivation/master key should be backed up or archived.

5103

B.6. Key Establishment (Automated)

5104

B.6.1. Symmetric Key-Wrapping Key

5105 5106

A symmetric key-wrapping key is used to wrap (i.e., encrypt and integrity protect) keying material for transmission in one or more messages.

5107 5108 5109

The backup of a symmetric key-wrapping key should be considered if a new symmetric keywrapping key cannot be readily and securely established with assurances of the identities of the sharing entities.

5110 5111

The archive of a symmetric key-wrapping key that is only used to transmit keying material may not be necessary.

5112

B.6.2. Key-Transport Key Pair

5113 5114

A key-transport key pair is used to transmit keying material from a sending entity to a receiving entity during communications. The sending entity uses the public key-transport key

157

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5115 5116

to encrypt the keying material; the receiving entity uses the private key to decrypt the received, encrypted keying material.

5117

B.6.2.1. Public Key-Transport Key

5118 5119 5120 5121 5122 5123

The backup or archiving of a public key-transport key may be done but may not be necessary. If the sending entity loses the other party’s public key-transport key or determines that the key has been corrupted, the key can be reacquired from the key-pair owner (i.e., the other party) if the sending entity has assurance of the identity of the party actually providing the public key or by obtaining a public-key certificate containing the public key (if the public key was certified).

5124

B.6.2.2 Private Key-Transport Key

5125 5126 5127 5128

A private key-transport key should be backed up or archived unless 1) a new key pair can be quickly generated and the public key provided to a sending entity (with assurance of the identity of the key-pair owner providing the new public key) or 2) an alternative key pair has already been generated and the public key made available (e.g., in a certificate).

5129 5130 5131

If the received, encrypted keying material is stored for later decryption, then the private keytransport key should be backed up or archived. See Appendix B.8.2 for a discussion of stored keys.

5132

B.6.3. Symmetric Key-Agreement Key

5133 5134 5135

A symmetric key-agreement key is used during communications to establish keying material (e.g., symmetric key-wrapping keys, symmetric data-encryption keys, symmetric authentication keys, or IVs). Each key-agreement key is shared between two or more entities.

5136 5137

If these keys are distributed manually (e.g., in a key-loading device or by receipted mail), then the symmetric key-agreement key should be backed up.

5138 5139 5140

If an automated means is available for quickly establishing new keys (e.g., a key-transport or key-encapsulation mechanism can be used to establish a new symmetric key-agreement key), then a symmetric key-agreement key need not be backed up.

5141

Symmetric key-agreement keys may be archived.

5142

B.6.4. Static Key-Agreement Key Pair

5143 5144 5145 5146 5147

A static key-agreement key pair is used to establish symmetric keying material between two entities (see [SP 800-56A] and [SP 800-56B]), sometimes in conjunction with ephemeral key pairs (see Appendix B.6.5 and [SP 800-56A]). In some key-agreement schemes, one of the entities (designated as the originating entity in [SP 800-56A]) uses only an ephemeral key pair rather than a static key-agreement key pair.

158

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5148 5149

In these schemes, each entity uses the other party’s public keys, their own private keys, and (in some schemes) their own public keys to generate shared keying material.

5150

B.6.4.1. Public Static Key-Agreement Key

5151

A public static key-agreement key need not be backed up if:

5152

1. The public key has been certified and can be obtained on request;

5153 5154 5155

2. The public key can be obtained from another entity (e.g., the owner of the key pair associated with the public static key-agreement key) with assurance of the owner’s identity;

5156 5157 5158

3. The entity intending to use the public key in a key-agreement computation is the owner of the static key-agreement key pair, and the public key can be recomputed (e.g., using the private static key-agreement key); or

5159 5160 5161 5162 5163

4. The entity intending to use the public key in a key-agreement computation is the owner of the key pair, and a new key pair can be generated and securely established in a timely fashion (i.e., with assurance of the identity of the owner). A newly generated public static key-agreement key can then be provided to the other entity participating in the key-agreement process.

5164

Otherwise, the public static key-agreement key should be backed up.

5165

The public key may be archived.

5166

B.6.4.2. Private Static Key-Agreement Key

5167 5168 5169

If a private static key-agreement key cannot be replaced in a timely manner, or if it needs to be retained to recover previously agreed-upon keying material, then the private key should be backed up in order to continue operations.

5170

The private key may be archived.

5171

B.6.5. Ephemeral Key-Agreement Key Pair

5172 5173 5174 5175 5176

An ephemeral key-agreement key pair is generated and the public key distributed during a single key-agreement transaction (e.g., at the beginning of a communication session) and must not be reused. This key pair is used to establish shared keying material (often in combination with static key pairs). Not all key-agreement schemes use ephemeral key pairs, and when used, not all entities use an ephemeral key pair (see [SP 800-56A]).

5177

B.6.5.1. Public Ephemeral Key-Agreement Key

5178 5179 5180

A public ephemeral key-agreement key may be backed up or archived. This may allow for the reconstruction of the established keying material at a later time as long as the corresponding private ephemeral key is not required in the reconstruction computation. 159

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5181

B.6.5.2. Private Ephemeral Key-Agreement Key

5182 5183 5184 5185

A private ephemeral key-agreement key shall not be backed up or archived. 55 If the private ephemeral key is lost or corrupted, a new key pair may be generated, and the new public ephemeral key may be provided to the other participating entity in the key-agreement process.

5186

B.6.6. Static Encapsulation/Decapsulation Key Pair

5187 5188 5189 5190

A public static encapsulation key is used by a sending entity to generate and encapsulate a symmetric key to be provided to the owner of the encapsulation/decapsulation key pair. The owner of the key pair uses the corresponding private static decapsulation key to decapsulate the received, encapsulated key.

5191

B.6.6.1. Public Static Encapsulation Key

5192 5193 5194 5195 5196

Backing up or archiving the public static encapsulation key may not be necessary if the key can be reacquired from the key-pair owner or by obtaining the public-key certificate that contains the public static encapsulation key (assuming that the public key was certified). Otherwise, a new public static key encapsulation key may be requested from the intended receiving entity.

5197

B.6.6.2. Private Static Decapsulation Key

5198

A private static decapsulation key should be backed up or archived until no longer needed.

5199

B.6.7. Ephemeral Encapsulation/Decapsulation Key Pair

5200 5201 5202 5203 5204 5205

An ephemeral encapsulation/decapsulation key pair is generated and used during a single key-establishment transaction and shall not be reused (see [SP 800-227]). A public ephemeral encapsulation key is used by a sending entity to generate and encapsulate a symmetric key to be provided to the owner of the encapsulation/decapsulation key pair. The owner of the key pair uses the corresponding private ephemeral decapsulation key to decapsulate the received, encapsulated key.

5206

B.6.7.1. Public Ephemeral Encapsulation Key

5207 5208 5209

A public ephemeral encapsulation key need not be backed up or archived since it is only used for a single key-establishment transaction and then destroyed. If unavailable, the owner of the ephemeral encapsulation/decapsulation key pair can be asked to resend the public key

55 [SP 800-56A] states that the private ephemeral keys shall be destroyed immediately after use. This implies that the private ephemeral keys shall not be backed up or archived.

160

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5210 5211

or to generate another key pair and provide the new public ephemeral encapsulation key (with assurance of the identity from the owner in both cases).

5212

B.6.7.2. Private Ephemeral Decapsulation Key

5213 5214 5215 5216

A private ephemeral decapsulation key need not be backed up by the owner if it is intended to be used immediately upon receipt of a key that was encapsulated using the corresponding public ephemeral encapsulation key. If the private key is unavailable at that time, then a new ephemeral key pair can be generated and the public key provided to the other entity.

5217 5218 5219 5220

If the received key is not decapsulated upon receipt of the encapsulated key or the decapsulation key may be used to decapsulate the received key at a later time, then the private ephemeral decapsulation key should be backed up or archived (see Appendix B.8 for a discussion of keys in storage).

5221

B.7. Symmetric Data Encryption/Decryption Keys

5222 5223 5224

A symmetric data-encryption key is used to protect the confidentiality of transmitted or stored data. The same key is used to encrypt the plaintext data to be protected and later to decrypt the encrypted data (i.e., the ciphertext), thus obtaining the original plaintext.

5225 5226

The key needs to be available for as long as any data that is encrypted using that key may need to be decrypted.

5227

B.7.1. Encryption/Decryption of Data in Transit

5228 5229

A symmetric data-encryption key that is used only for transmission is used by a sending entity to encrypt data and by the receiving entity to decrypt the ciphertext data.

5230 5231 5232 5233

•

Case 1: The sending entity no longer has an encryption key that is shared with the intended receiver. If a new encryption/decryption key can be readily generated and distributed, then these keys need not be backed up or archived. Otherwise, the keys should be backed up or archived until no longer needed.

5234 5235 5236 5237

•

Case 2: The receiving entity always decrypts data immediately upon receipt. The encryption/decryption key should be backed up or archived until no longer needed (see Appendices B.7.2 and B.8) unless a new encryption/decryption key can be readily generated and distributed.

5238 5239 5240

•

Case 3: The receiving entity stores the received ciphertext for later decryption. The encryption/decryption key should be backed up or archived until no longer needed (see Appendices B.7.2 and B.8).

5241

B.7.2.

5242 5243

The symmetric data-encryption key should be stored in backup storage during the cryptoperiod of the key and should be stored in archive storage if required beyond the

Encryption/Decryption of Data at Rest

161

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5244 5245

originator-usage period of the key. In many cases, the key is protected and stored with the encrypted data (see Appendix B.8).

5246

B.8. Keying Material Storage

5247 5248 5249 5250 5251 5252 5253 5254 5255

Keys and other related information (i.e., KRI) may be stored in operational storage within the computer (e.g., RAM), within hardware designed to protect the keys, or on external storage media (e.g., backed up or archived for storage at a remote location) (see Sec. 5.2.2.7). When protection is not inherently provided by the storage medium, the confidentiality and integrity of the stored key needs to be assured using a backup or archive confidentiality key to encrypt, wrap, or encapsulate the stored key and possibly an integrity protection key when the integrity protection is not provided by the encrypting, wrapping, or encapsulation process. The key-storage medium may be organized as a tree structure with multiple layers of keys (see Fig. 6).

5256 5257

Fig. 6. Example of a tree of keys in storage

5258 5259

Presumably, the lowest layer of keys is used to encrypt data other than keys. The security of each layer depends (in part) on the security of the layers above it.

5260 5261 5262 5263

Using the example depicted in Fig. 6, the highest layer key could be an asymmetric keywrapping key pair (e.g., an RSA key pair) used for confidentiality protection for the next layer of keys. A different key pair might be used for each organization. In Fig. 6, the public wrapping key for Organization 1 might be eKey1, and the corresponding private unwrapping key might 162

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

5264 5265 5266 5267 5268 5269 5270 5271 5272 5273 5274

Recommendation for Key Management Part 1 — General

be dKey1. Organization 1 has several applications and uses a symmetric key-wrapping algorithm (e.g., AES-CCM) with different key-wrapping keys (shown as KeyA, KeyB, and KeyC) to protect data keys for each application (i.e., applications A, B, and C, respectively). Application B has generated multiple data keys to protect its data (DEK1, DEK2, …) using AESCCM and its wrapping key KeyB. In this example, data key DEK1 has been used to encrypt plaintext data using AES-CCM: EncryptedData = ENCRYPTAES-CCM(DEK1, PlaintextData).

(1)

DEK1 is wrapped using AES-CCM and KeyB: Wrapped DEK1 = WRAPAES-CCM(KeyB, DEK1),

(2)

and KeyB is wrapped using RSA and eKey1: Wrapped KeyB = WRAPRSA(eKey1, KeyB).

(3)

5275 5276 5277

Wrapped KeyB, Wrapped DEK1, and the EncryptedData are stored. The highest-layer key in the tree (dKey1) shall be securely stored offline when not protected by the storage system (e.g., in a safe with dual access control).

5278 5279

In order to access the data protected by DEK1 (i.e., the plaintext data), the private unwrapping key (dKey1) is used to unwrap Organization 1’s symmetric-unwrapping key KeyB:

5280 5281 5282 5283 5284

KeyB = UNWRAPRSA(dkey1, Wrapped KeyB),

(4)

the symmetric unwrapping key (KeyB) is then used to unwrap DEK1: DEK1 = UNWRAPAES-CCM(KeyB, Encrypted DEK1),

(5)

and DEK1 is used to decrypt the data it protects. PlaintextData = DECRYPTAES-CCM(DEK1, EncryptedData).

(6)

5285

B.8.1. Symmetric Key Wrapping/Unwrapping Key

5286 5287 5288 5289 5290

A symmetric key-wrapping key is used to wrap (i.e., encrypt and integrity protect) keying material for storage and may be used to protect multiple sets of keying material (see equation 2 in Appendix B.8, for example). The symmetric key-wrapping key should be archived or stored offline (e.g., in a safe with dual access control) until no longer needed to unwrap keying material previously wrapped using the key.

5291

B.8.2. Asymmetric Key Encryption/Decryption Key Pair

5292 5293 5294 5295

An asymmetric public key-encryption key may be used to encrypt keying material for storage (see equation 3 in Appendix B.8, for example). The corresponding private decryption key is used to decrypt the keying material, when needed (see equation 6 in Appendix B.8, for example).

163

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5296

B.8.2.1. Public Key-Wrapping Key

5297 5298

Backing up or archiving a public key-wrapping key is not necessary, assuming that another key encryption/decryption key pair can be readily generated.

5299

B.8.2.2. Private Key-Unwrapping Key

5300 5301

A private key-unwrapping key should be backed up or archived for as long as the keying material encrypted by the corresponding public key-encryption key needs to be accessed.

5302

B.8.3. Encapsulation/Decapsulation Key Pair

5303 5304 5305

An encapsulation key could be used to encapsulate a symmetric key for protecting keys or data in storage. The corresponding decapsulation key would be used to decapsulate the encapsulated key.

5306

B.8.3.1. Public Encapsulation Keys

5307 5308

Backing or archiving the public encapsulation key is not necessary, assuming that another encapsulation/decapsulation key pair can be readily generated.

5309

B.8.3.2. Private Decapsulation Keys

5310 5311

A private decapsulation key should be backed up, archived, or stored offline for as long as the encapsulated keying material may need to be accessed.

5312

B.9. Authorization

5313

B.9.1. Symmetric Authorization Key

5314 5315 5316 5317 5318

A symmetric authorization key is used to provide privileges to an entity (e.g., access to certain data or authorization to perform certain functions). The loss of this key will deny the privileges (e.g., prohibit access and disallow the performance of these functions). If the authorization key is lost or corrupted and can be replaced in a timely fashion, then the authorization key need not be backed up. A symmetric authorization key shall not be archived.

5319

B.9.2. Authorization Key Pair

5320 5321 5322

An authorization key pair is used to determine the privileges that an entity may assume. The private key is used to establish the “right” to the privilege. The corresponding public key is used to determine that the entity has the right to the privilege.

164

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5323

B.9.2.1. Private Authorization Key

5324 5325 5326 5327

The loss of a private authorization key will deny privileges (e.g., prohibit access and disallow the performance of certain functions requiring authorization). If the private key is lost or corrupted and can be replaced in a timely fashion, then the private key need not be backed up. Otherwise, the private key should be backed up. The private key shall not be archived.

5328

B.9.2.2. Public Authorization Key

5329 5330 5331 5332 5333 5334

If an authorization key pair can be replaced in a timely fashion (i.e., by a regeneration of the key pair and secure distribution of the private key to the entity seeking authorization), then the public authorization key need not be backed up. Otherwise, a public authorization key should be backed up. There is no need to archive the public authorization key, since authorization is only granted using the corresponding private authorization key, which is not archived (see Appendix B.9.2.1).

5335

B.10. Other Related Information

5336 5337

Like keys, other related information may need to be backed up or archived, depending on its use.

5338

B.10.1. Algorithm Parameters

5339 5340 5341 5342

Algorithm parameters are used in conjunction with some public-key algorithms to generate key pairs or perform basic algorithm functions. Algorithm parameters should be backed up or archived if not obtainable from another trusted source (e.g., a PKI certificate) or if any new algorithm parameters cannot be securely distributed in a timely fashion.

5343

B.10.2. Initialization Vector (IV)

5344 5345 5346 5347

An IV is used in several modes of operation during the encryption or authentication of data using block cipher algorithms. An IV is often stored with the data that it protects. If not stored with the data, an IV should be backed up or archived as long as the data protected using the IV needs to be processed (e.g., decrypted or authenticated).

5348

B.10.3. Shared Secret

5349 5350 5351 5352 5353

A shared secret is generated by each entity that participates in a key-agreement process. The shared secret is then used to derive the shared keying material to be used in subsequent cryptographic operations. A shared secret may be generated during interactive communications (e.g., where both entities are online) or during non-interactive communications (e.g., in store-and-forward applications).

5354

A shared secret shall not be backed up or archived.

165

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5355

B.10.4. Seed

5356 5357 5358 5359

A seed is used for the generation of random bits or keying material. When used for the generation of random bits, the seed shall not be backed up or archived but may be replaced. When used for the regeneration (i.e., reconstruction) of keying material, the seed may be backed up or archived.

5360

B.10.5. Other Public and Secret Information

5361 5362 5363 5364

Public and secret information is often used during key establishment. The information may need to be available to identify the key that is needed to process cryptographically protected data (e.g., to decrypt or authenticate). In this case, the information should be backed up or archived until no longer needed to process the protected data.

5365

B.10.6. Intermediate Results

5366 5367

Except for the generation and use of seeds (see Appendix B.10.4), the intermediate results of a cryptographic operation shall not be backed up or archived.

5368

B.10.7. Key-Control Information/Metadata

5369 5370 5371 5372

Key-control information may be used to determine the key and other information to be used to process cryptographically protected data (e.g., decrypt or authenticate), identify the purpose of the key, or identify the entities that share the key (see Sec. 5.2.3). This information may be contained in the key’s metadata.

5373 5374

Key-control information should be backed up or archived for as long as the associated key needs to be available.

5375

B.10.8. Random Numbers

5376 5377

A random number is generated by a random number generator. The backup or archiving of a random number depends on how it is used.

5378

B.10.9. Password

5379 5380

A password is used to acquire access to privileges by an entity, derive a key, or detect the reuse of a password.

5381 5382 5383

If the password is only used to acquire access to privileges and can be replaced in a timely fashion, then the password need not be backed up. In this case, a password shall not be archived.

5384 5385

If the password is used to derive a cryptographic key or prevent the reuse of a password, the password should be backed up and archived.

166

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5386

B.10.10. Audit Information

5387

Audit information containing key-management events shall be backed up and archived.

5388

167

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5389

Appendix C. Security Strength Categories for Post-Quantum Algorithms

5390 5391 5392 5393

There are potentially significant uncertainties in estimating the security strengths of postquantum cryptosystems. New quantum algorithms may be discovered, leading to new cryptanalytic attacks, and there is a limited ability to predict the performance characteristics of future quantum computers, such as their cost, speed, and memory size.

5394 5395 5396 5397 5398 5399

In order to address these uncertainties, NIST developed a collection of broad security strength categories 56 in order to evaluate post-quantum algorithm candidates [NIST PQC eval]. Each category is defined by a comparatively easy-to-analyze reference primitive whose security serves as a floor for a wide variety of metrics that are potentially relevant to practical security. A given cryptosystem may be instantiated using different parameter sets in order to fit into different categories. The goals of this classification are to:

5400 5401 5402

1. Facilitate meaningful performance comparisons between the submitted algorithms by striving to ensure that the parameter sets being compared provide comparable security

5403 5404

2. Enable an organization to make prudent future decisions regarding when to transition to longer keys

5405 5406 5407

3. Permit consistent and sensible choices regarding what symmetric primitives to use in padding mechanisms or other components of schemes that require symmetric cryptography

5408 5409

4. Better understand the security and performance trade-offs involved in a given design approach

5410 5411 5412 5413 5414

In accordance with the second and third goals above, the categorization approach is based on the range of security strengths offered by existing NIST standards in symmetric cryptography, which have been identified as offering significant resistance to quantum cryptanalysis. The approach also considers a variety of possible metrics that reflect different predictions about the future development of quantum and classical computing technology.

5415 5416

The categorization approach considers a variety of possible metrics, reflecting different predictions about the future development of quantum and classical computing technology.

5417 5418 5419 5420 5421 5422 5423 5424

One of the metrics for measuring the complexity of quantum attacks during the NIST PQC standardization process is designated as MAXDEPTH, which was motivated by the difficulty of running extremely long serial computations. Plausible values for MAXDEPTH range from 240 logical gates (i.e., the approximate number of gates that quantum computing architectures were expected to serially perform in a year) through 264 logical gates (i.e., the approximate number of gates that classical computing architectures could serially perform in a decade) to no more than 296 logical gates (i.e., the approximate number of gates that atomic scale qubits with speed of light propagation times could perform in a millennium) [Jones].

5425 5426

The complexity of quantum attacks can be measured in terms of circuit size (see [Grassl]). These numbers can be compared to the resources required to break AES and SHA3. NIST gave 56 The five defined categories are specified in Sec. 4.6.1.

168

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

5427 5428

Recommendation for Key Management Part 1 — General

the following estimates for classical and quantum gate counts for optimal key recovery and collision attacks on AES and SHA3, respectively, where circuit depth is limited to MAXDEPTH:

5429

•

AES 128

2170/MAXDEPTH quantum gates or 2143 classical gates

5430

•

SHA3-256

2146 classical gates

5431

•

AES 192

2233/MAXDEPTH quantum gates or 2207 classical gates

5432

•

SHA3-384

2210 classical gates

5433

•

AES 256

2298/MAXDEPTH quantum gates or 2272 classical gates

5434

•

SHA3-512

2274 classical gates

5435 5436 5437 5438

NIST believes that these estimates are accurate for the majority of values of MAXDEPTH that are relevant to the security analysis of the post-quantum algorithms, but the estimates may understate the security of SHA for very small values of MAXDEPTH and may understate the quantum security of AES for very large values of MAXDEPTH.

169

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5439

Appendix D. List of Abbreviations and Acronyms

5440 5441

2TDEA Two-Key Triple Data Encryption Algorithm

5442 5443

3TDEA Three-key Triple Data Encryption Algorithm

5444 5445

AEAD Authenticated Encryption with Associated Data

5446 5447

AES Advanced Encryption Standard

5448 5449

ANS American National Standard

5450 5451

ANSI American National Standards Institute

5452 5453

CA Certification Authority

5454 5455

CAVP Cryptographic Algorithm Validation Program

5456 5457

CKL Compromised Key List

5458 5459

CRC Cyclic Redundancy Check

5460 5461

CRL Certificate Revocation List

5462 5463

CMAC Cipher-Based Message Authentication Code

5464 5465

CMVP Cryptographic Module Validation Program

5466 5467

DES Data Encryption Standard

5468 5469

DH Diffie-Hellman

5470 5471

DRBG Deterministic Random Bit Generator

5472 5473

DSA Digital Signature Algorithm

5474 5475

ECC Elliptic Curve Cryptography

170

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5476 5477

ECDH Elliptic Curve Diffie-Hellman

5478 5479

ECDSA Elliptic Curve Digital Signature Algorithm

5480 5481

EdDSA Edwards-Curve Digital Signature Algorithm

5482 5483

FFC Finite Field Cryptography

5484 5485

FIPS Federal Information Processing Standards

5486 5487

HMAC Keyed-Hash Message Authentication Code

5488 5489

HSM Hardware Security Module

5490 5491

IC Integrated Circuit

5492 5493

IFC Integer Factorization Cryptography

5494 5495

IP Internet Protocol

5496 5497

ISO/ITU-T International Organization for Standardization/International Telecommunication Union − Telecommunication

5498 5499

ITL Information Technology Laboratory

5500 5501

IV Initialization Vector

5502 5503

KMAC Keccak-Based Message Authentication Code

5504 5505

KRI Key-Recovery Information

5506 5507

KRS Key-Recovery System

5508 5509

MAC Message Authentication Code

5510 5511

ML-DSA Module-Lattice-Based Digital Signature Standard

5512 5513

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

171

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

5514 5515

MQV Menezes-Qu-Vanstone

5516 5517

NIST National Institute of Standards and Technology

5518 5519

PKI Public-Key Infrastructure

5520 5521

POP Proof of Possession

5522 5523

PQC Post-Quantum Cryptography

5524 5525

RA Registration Authority

5526 5527

RAM Random Access Memory

5528 5529

RBG Random Bit Generator

5530 5531

RNG Random Number Generator

5532 5533

RSA Rivest–Shamir–Adelma

5534 5535

S/MIME Secure Multipurpose Internet Mail Extensions

5536 5537

SHA-2 Secure Hash Algorithm 2

5538 5539

SHA-3 Secure Hash Algorithm 3

5540 5541

SHAKE Secure Hash Algorithm KECCAK

5542 5543

SLH-DSA Stateless Hash-Based Digital Signature Algorithm

5544 5545

SSH Secure Shell Protocol

5546 5547

TDEA Triple Data Encryption Algorithm

5548 5549

TLS Transport Layer Security

5550 5551

TPM Trusted Platform Module

Recommendation for Key Management Part 1 — General

172

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

5552 5553

XOF eXtendable-Output Function

5554 5555

USB Universal Serial Bus

Recommendation for Key Management Part 1 — General

173

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

5556

Recommendation for Key Management Part 1 — General

Appendix E. Glossary

5557 5558

access control Restricts resource access to only authorized entities.

5559 5560

accountability 1. Assigning key management responsibilities to individuals and holding them accountable for these activities.

5561

2. A property that ensures that the actions of an entity may be traced uniquely to that entity.

5562 5563 5564 5565

active state The key state in which the key may be used to cryptographically protect information (e.g., encrypt plaintext, or generate a digital signature), cryptographically process previously protected information (e.g., decrypt ciphertext or verify a digital signature), or both.

5566 5567 5568

algorithm originator-usage period The period of time during which a specific symmetric-key algorithm may be used by originators to apply protection to data (e.g., encrypt or generate a MAC).

5569 5570 5571

algorithm parameters Parameters used in conjunction with some public-key algorithms to generate key pairs or to perform cryptographic operations (e.g., create digital signatures or establish keying material).

5572 5573 5574

algorithm security lifetime The estimated time period during which data protected by a specific cryptographic algorithm is estimated to remain secure, given that the key has not been compromised.

5575 5576 5577

approved FIPS-approved and/or NIST-recommended. An algorithm or technique that is either 1) specified in a FIPS or NIST recommendation or 2) specified elsewhere and adopted by reference in a FIPS or NIST recommendation.

5578 5579

archive 1. To place information into long-term storage.

5580

2. A location or media used for long-term storage.

5581 5582 5583

association A relationship for a particular purpose, such as a key associated with the application or process for which it will be used.

5584 5585 5586

assurance of (private-key) possession Confidence that an entity possesses a private key and its associated key information and that the private key corresponds to a given public key.

5587 5588

assurance of validity Confidence that a public key or domain parameter is correct.

5589 5590

asymmetric-key algorithm See public-key cryptographic algorithm.

5591 5592 5593 5594

authentication A process that provides assurance of the source and integrity of information in communication sessions, messages, documents, or stored data or that provides assurance of the identity of an entity interacting with a system. See source authentication, identity authentication, and integrity authentication.

174

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5595 5596 5597

authentication code A keyed cryptographic checksum based on an approved security function. Also known as a message authentication code.

5598 5599 5600

authorization Access privileges that are granted to an entity that convey an “official” sanction to perform a security function or activity.

5601 5602

availability Timely, reliable access to information by authorized entities.

5603 5604

backup A copy of key information to facilitate recovery during the cryptoperiod of the key, if necessary.

5605 5606 5607 5608

block cipher (algorithm) A symmetric-key cryptographic algorithm that transforms one block of information at a time using a cryptographic key. For a block cipher algorithm, the length of the input block is the same as the length of the output block.

5609 5610

certificate See public-key certificate.

5611 5612

certificate-inventory management See key-inventory management.

5613 5614

certification authority A trusted party in a public-key infrastructure (PKI) that issues public-key certificates to certificate subjects.

5615 5616

certificate subject The entity authorized to use the private key associated with the public key in a public-key certificate.

5617 5618

ciphertext Data in its encrypted form.

5619 5620

collision Two or more distinct inputs produce the same output. Also see hash function.

5621 5622 5623

compromise The unauthorized disclosure, modification, substitution, or use of sensitive key information (e.g., secret key, private key, or secret metadata).

5624 5625

compromised state A key state to which a key is transitioned when there is suspicion or confirmation of the key’s compromise.

5626 5627 5628

confidentiality The property that sensitive information is not disclosed to unauthorized entities (e.g., the secrecy of the key information is maintained).

5629 5630 5631

contingency plan A plan that is maintained for disaster response, backup operations, and/or post-disaster recovery to ensure the availability of critical resources and to facilitate the continuity of operations in an emergency situation.

5632 5633

contingency planning The development of a contingency plan.

175

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5634 5635 5636

cryptanalysis 1. Operations performed to defeat cryptographic protection without initial knowledge of the key employed in providing the protection.

5637 5638 5639

2. The study of mathematical techniques for attempting to defeat cryptographic techniques and informationsystem security. This includes the process of looking for errors or weaknesses in the implementation of an algorithm or in the design of the algorithm itself.

5640 5641 5642

cryptographic algorithm A well-defined computational procedure that takes variable inputs, often including a cryptographic key, and produces an output.

5643 5644 5645

cryptographic boundary An explicitly defined continuous perimeter that establishes the physical bounds of a cryptographic module and contains all hardware, software, and/or firmware components of a cryptographic module.

5646 5647 5648

cryptographic element The cryptographic algorithm, scheme, parameter choice, and/or key of a particular type, length, or strength used by a cryptographic service.

5649 5650

cryptographic hash function See hash function.

5651 5652 5653 5654

cryptographic key (key) A parameter used in conjunction with a cryptographic algorithm that determines its operation in such a way that an entity with knowledge of the key can reproduce, reverse, or verify the operation while an entity without knowledge of the key cannot.

5655 5656 5657

cryptographic module The set of hardware, software, and/or firmware that implements approved security functions and is contained within a cryptographic boundary. Also see security function.

5658 5659 5660

cryptoperiod The time span during which a specific key is authorized for use or in which the keys for a given system or application may remain in effect.

5661 5662

data-encryption key A key used to encrypt and decrypt data other than keys.

5663 5664 5665

data integrity A property whereby data has not been altered in an unauthorized manner since it was created, transmitted, or stored.

5666 5667 5668 5669

decapsulation A key-establishment procedure in which a symmetric key is produced from ciphertext using a private decapsulation key and a key-encapsulation mechanism (KEM). See encapsulation and key-encapsulation mechanism.

5670 5671

decryption The process of changing ciphertext into plaintext using a cryptographic algorithm and key.

5672 5673 5674

destroy (a key or other data) An action applied to a key or other data after which no information about its value can be recovered. Other terms often used are delete, destroy, zeroize, and sanitize.

176

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5675 5676 5677

destroyed state A key state to which a key transitions when it is destroyed. Although the key no longer exists, its previous existence may be recorded (e.g., in metadata or audit logs).

5678 5679

destruction (of a key or other data) See destroy.

5680 5681 5682 5683 5684

deterministic random bit generator (DRBG) A random bit generator that includes a DRBG algorithm and (at least initially) has access to a source of randomness. The DRBG produces a sequence of bits from a secret initial value called a seed. A cryptographic DRBG has the additional property that the output is unpredictable given that the seed is not known. A DRBG is sometimes also called a pseudorandom number generator (PRNG) or a deterministic random number generator.

5685 5686 5687 5688

digital signature The result of a cryptographic transformation of data that, when properly implemented with a supporting infrastructure and policy, provides source or identity authentication, data integrity authentication, and/or support for signer non-repudiation.

5689 5690 5691 5692

encapsulation A key-establishment procedure in which a random symmetric key and corresponding ciphertext value is generated using a public encapsulation key and a key-encapsulation mechanism (KEM). See key-encapsulation mechanism and decapsulation.

5693 5694 5695

encrypted key A cryptographic key that has been encrypted using an approved cryptographic algorithm to disguise the value of the underlying plaintext key.

5696 5697

encryption The process of changing plaintext into ciphertext using a cryptographic algorithm and key.

5698 5699

entity An individual (person), organization, device, or process.

5700 5701 5702

entity registration A function in the life cycle of a cryptographic key. A process whereby an entity becomes a member of a security domain.

5703 5704 5705

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

5706 5707 5708 5709

eXtendable-Output Function (XOF) A function on bit strings in which the length of the output can be extended to any length. Approved XOFs (e.g., those specified in [FIPS 202] and [SP 800-232]) are designed to satisfy the following properties as long as the specified output length is sufficiently long to prevent trivial attacks:

5710

1. (One-way) It is computationally infeasible to find any input that maps to any new pre-specified output.

5711 5712

2. (Collision-resistant) It is computationally infeasible to find any two distinct inputs that map to the same output.

5713 5714

hash-based message authentication code (HMAC) A message authentication code that uses an approved hash function and a key (i.e., see [SP 800-224]).

5715 5716 5717

hash function A function that maps a bit string of arbitrary (although bounded) length to a fixed-length bit string. Approved hash functions satisfy the following properties:

177

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5718

1. (One-way) It is computationally infeasible to find any input that maps to any pre-specified output.

5719 5720

2. (Collision-resistant) It is computationally infeasible to find any two distinct inputs that map to the same output.

5721 5722 5723 5724

hashing method An algorithm that takes an input bit string of arbitrary length and produces an output with a given length. A hashing method does not require a cryptographic key. Two methods for hashing have been approved: (cryptographic) hash functions and eXtendable-Output Functions.

5725 5726

hash value The result of applying a hashing method to information.

5727 5728 5729

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 and timestamp), depending on the application.

5730 5731

identity The distinguishing characteristic or personality of an entity.

5732 5733 5734

identity authentication The process of providing assurance about the identity of an entity interacting with a system (e.g., to access a resource). Sometimes called entity authentication.

5735 5736

initialization vector (IV) A vector used in defining the starting point of a cryptographic process.

5737 5738

integrity See data integrity.

5739 5740 5741

integrity authentication The process of obtaining assurance that data has not been modified since an authentication code or digital signature was created for that data.

5742 5743 5744

integrity protection The protection obtained for transmitted or stored data using an authentication code (e.g., MAC) or digital signature computed on that data. See integrity authentication.

5745 5746

key See cryptographic key.

5747 5748 5749 5750

key agreement A key-establishment procedure in which keying material is generated from information contributed by two or more participants so that no party can predetermine the value of the keying material independently of any other party’s contribution.

5751 5752 5753

key confirmation A procedure used to provide assurance to one party that another party actually possesses the same keying material and/or shared secret.

5754 5755 5756

key de-registration A function in the life cycle of a cryptographic key that involves marking the key or the information associated with it (e.g., metadata) to indicate that the key is no longer in use.

5757 5758 5759

key derivation The process by which keying material is derived from either a pre-shared key or a shared secret (from a keyagreement scheme) along with other information.

178

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5760 5761 5762

key-derivation function A function that generates a binary string called keying material using the input of a cryptographic key or shared secret and possibly other data.

5763 5764

key-derivation key A key used with a key-derivation method to derive additional keys. Sometimes called a “master key.”

5765 5766

key-derivation method A key-derivation function or other approved procedure for deriving keying material.

5767 5768

key destruction To remove all traces of a cryptographic key so that it cannot be recovered by either physical or electronic means.

5769 5770 5771

key distribution The transport of a key and other keying material from an entity that either owns, generates, or otherwise acquires the key to another entity that is intended to use the key.

5772 5773 5774

key-encapsulation mechanism (KEM) A set of three cryptographic algorithms — KeyGen, Encaps, and Decaps — that can be used by two parties to establish a shared secret key over a public channel. See encapsulation and decapsulation.

5775 5776 5777

key-encryption key A cryptographic key that is used for the encryption or decryption of other keys to provide confidentiality protection for those keys. Also see key-wrapping key.

5778 5779 5780 5781 5782

key establishment A function in the life cycle of a cryptographic key. The process by which cryptographic keys are securely established among entities using manual transport methods (e.g., key loaders), automated methods (e.g., keytransport, key-agreement, or key-encapsulation schemes), or a combination of automated and manual methods.

5783 5784 5785

key information Information about a key that includes the keying material and associated metadata related to that key. See keying material and metadata.

5786 5787 5788

key inventory Information about each key that does not include the key itself (e.g., key owner, key type, algorithm, application, or expiration date).

5789 5790 5791 5792

key-inventory (or certificate-inventory) management Establishing and maintaining records of the keys and/or certificates in use, assigning and tracking their owners or sponsors, monitoring key and certificate status, and reporting the status to the appropriate official for remedial action when required.

5793 5794

key length The length of a key in bits. Used interchangeably with “key size.”

5795 5796 5797

key management Activities that involve handling cryptographic keys and other related key information during the entire life cycle of the keys, including their generation, storage, establishment, entry, output, use, and destruction.

5798 5799 5800

key-management policy A high-level document that identifies a high-level structure, responsibilities, governing standards and guidelines, organizational dependencies and other relationships, and security policies.

179

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5801 5802 5803 5804

key-management system A system for the management of cryptographic keys and their metadata, including their generation, distribution, storage, backup, archive, recovery, use, revocation, and destruction. An automated key-management system may be used to oversee, automate, and secure the key-management process.

5805 5806 5807

key-management practices statement A document or set of documents that provides detailed descriptions of the organizational structure, responsible roles, and rules for the functions identified in the key-management policy.

5808 5809 5810

key owner An entity authorized to use a symmetric key or the private key of a public-key (asymmetric) key pair and whose identifier is associated with the key or key pair.

5811 5812

key pair A public key and its corresponding private key that are used with an asymmetric-key (public-key) algorithm.

5813 5814 5815

key recovery A possible function in the life cycle of a cryptographic key. Mechanisms and processes that allow authorized entities to retrieve or reconstruct a key.

5816 5817 5818

key registration A function in the life cycle of a cryptographic key. The process used by a registration authority to create an official record of keying material.

5819 5820 5821 5822

key revocation A possible function in the life cycle of a cryptographic key. A process whereby a notice is made available to affected entities that the key should be removed from operational use prior to the end of the established cryptoperiod of that key.

5823 5824 5825 5826

key share One of n parameters (where n ≥ 2) such that among the n key shares, any k key shares (where k ≥ n) can be used to construct a key value. Having any k−1 or fewer key shares provides no knowledge of the (constructed) key value. Sometimes called a “cryptographic key component” or “key split.”

5827 5828

key size The length of a key in bits. Used interchangeably with key length.

5829 5830 5831

key states The states through which a key transitions between its generation and its destruction. See pre-activation state, active state, suspended state, compromised state, and destroyed state.

5832 5833 5834

key transport A key-establishment procedure whereby one party (i.e., the sender) selects and encrypts (or wraps) the key and then distributes it to another party (i.e., the intended receiver).

5835 5836

When used in conjunction with a public-key (asymmetric) algorithm, the key is encrypted using the public key of the receiver and subsequently decrypted using the receiver’s private key.

5837 5838

When used in conjunction with a symmetric algorithm, the key is encrypted with a key-wrapping key shared by the sending and receiving parties and decrypted using the same key.

5839 5840 5841

key update A function performed on a cryptographic key to compute a new key that is related to the old key and is used to replace that key.

5842

Note: This recommendation disallows this method of replacing a key.

180

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5843 5844

key wrapping A method of cryptographically protecting keys that provides both confidentiality and integrity protection.

5845 5846 5847

key-wrapping key A key that is used to provide both confidentiality and integrity protection for other keys. Also see key-encryption key.

5848 5849 5850

keying material A cryptographic key and other parameters (e.g., IVs or algorithm parameters) used with a cryptographic algorithm.

5851 5852 5853

manual key transport A manual (i.e., non-automated) means of transporting cryptographic keys by physically moving a device or document that contains the key or key share.

5854 5855

master key See key-derivation key.

5856 5857 5858

message authentication code (MAC) A cryptographic checksum on data that uses an approved security function and a symmetric key to detect both accidental and intentional modifications of data.

5859 5860 5861

metadata The information associated with a key that describes its specific characteristics, constraints, acceptable uses, and ownership. Sometimes called the key’s “attributes.”

5862 5863

NIST standards Federal Information Processing Standards (FIPS) publications and NIST recommendations.

5864 5865 5866

non-repudiation A service provided using a digital signature to support a determination by a third party of whether a message was actually signed by a given entity.

5867 5868

operational phase A phase in the life cycle of a cryptographic key whereby the key is used for standard cryptographic purposes.

5869 5870

operational storage The normal storage of operational keying material during a key’s cryptoperiod.

5871 5872 5873

owner (of a certificate) A human entity who is identified as the subject in a public-key certificate or is a sponsor of a non-human entity (e.g., device, application, or process) that is identified as the certificate subject.

5874 5875 5876 5877

owner (of a key or key pair) For a static key pair, the entity that is associated with the public key and authorized to use the private key. For an ephemeral key pair, the entity that generated the public/private key pair. For a symmetric key, any entity that is authorized to use the key.

5878 5879

originator An entity that initiates an information exchange or storage event.

5880 5881 5882

originator-usage period The period of time in the cryptoperiod of a symmetric key during which cryptographic protection may be applied to data using that key.

181

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5883 5884 5885

password A string of characters (i.e., letters, numbers, and other symbols) that are used to authenticate an identity, verify access authorization, or derive cryptographic keys.

5886 5887

period of protection The period of time during which the integrity or confidentiality of a key needs to be maintained.

5888 5889

plaintext Intelligible data that has meaning and can be understood without the application of decryption.

5890 5891

pre-activation state A key state in which the key has been generated but is not yet authorized for use.

5892 5893 5894 5895

private key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and is not made public. In an asymmetric-key (public-key) cryptosystem, the private key has a corresponding public key.

5896 5897 5898

proof-of-possession (POP) A verification process whereby assurance is obtained that the owner of a key pair actually has the private key associated with the public key.

5899 5900

pseudorandom number generator See deterministic random bit generator (DRBG).

5901 5902 5903 5904

public key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and that may be made public. In an asymmetric-key (public-key) cryptosystem, the public key has a corresponding private key.

5905 5906 5907 5908 5909

public-key certificate A set of data that provides a unique identifier for the owner of the certificate, contains that entity’s public key and possibly other information, and is digitally signed by a trusted party (e.g., a CA), thereby binding the public key to the entity’s identifier. Additional information in the certificate could specify how the key is used and its validity period.

5910 5911 5912

public-key (asymmetric-key) cryptographic algorithm A cryptographic algorithm that uses two related keys: a public key and a private key. The two keys have the property that determining the private key from the public key is computationally infeasible.

5913 5914

public-key infrastructure (PKI) A framework that is established to issue, maintain, and revoke public-key certificates.

5915 5916 5917

random bit generator (RBG) A device or algorithm that outputs a sequence of bits that appears to be statistically independent and unbiased. Also see random number generator.

5918 5919

random number generator (RNG) A process used to generate an unpredictable series of numbers. Also called a random bit generator (RBG).

5920 5921 5922

recipient-usage period The period of time during which protected information may be processed (e.g., decrypted) using a symmetric algorithm and symmetric key.

5923 5924

registration authority (RA) A trusted entity that establishes and vouches for the identity of a user.

182

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5925 5926 5927 5928

relying party A party that relies on the security and authenticity of a key or key pair to apply cryptographic protection and/or remove or verify the protection that has been applied. This includes parties that rely on the public key in a public-key certificate and parties that share a symmetric key.

5929 5930

representative (of a key owner) See sponsor (of a key).

5931 5932

retention period The minimum amount of time that a key or other cryptographically related information should be retained.

5933 5934

RBG seed A string of bits that is used to initialize a DRBG. Also called a seed.

5935 5936 5937 5938

secret key A single cryptographic key that is used with a symmetric-key cryptographic algorithm, is uniquely associated with one or more entities, and is not made public (i.e., the key is kept secret). A secret key is also called a symmetric key.

5939 5940

Note: The use of the term “secret” in this context does not imply a classification level but rather implies the need to protect the key from disclosure.

5941 5942

secret-key algorithm See symmetric-key algorithm.

5943 5944 5945

secret-key information The key information that needs to be kept secret (e.g., symmetric keys, private keys, key shares, and secret metadata).

5946 5947 5948

security categories The evaluation criteria for the security strength of an algorithm in terms of the computational resources needed to break block cipher algorithms or hash functions.

5949 5950 5951

secure communication protocol A communication protocol that provides the appropriate confidentiality, source authentication, and integrity protection.

5952 5953 5954

security domain A system or subsystem that is under the authority of a single trusted authority. Security domains may be organized (e.g., hierarchically) to form larger domains.

5955 5956 5957 5958

security function Cryptographic algorithms, together with modes of operation (if appropriate); for example, block ciphers, digital signature algorithms, asymmetric key-establishment algorithms, message authentication codes, hash methods, or random bit generators. See [FIPS 140-3].

5959 5960 5961

security life of data The time period during which the security of the data needs to be protected (i.e., its confidentiality, integrity, or availability).

5962 5963 5964

security services Mechanisms used to provide confidentiality, identity authentication, integrity authentication, source authentication, and/or non-repudiation.

183

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

5965 5966 5967 5968

security strength A number associated with the amount of work (i.e., the number of operations) that is required to break a cryptographic algorithm or system. In this recommendation, the security strength is specified in bits and is a specific value from the set {112, 128, 192, 256}. Also called “bits of security.”

5969 5970 5971

seed A secret value that is used to initialize a process (e.g., initialize a DRBG) or generate keying material. Also see RBG seed.

5972 5973 5974 5975 5976

self-signed certificate A public-key certificate whose digital signature may be verified by the public key contained within the certificate. The signature on a self-signed certificate protects the integrity of the information within the certificate but does not guarantee the authenticity of that information. The trust of self-signed certificates is based on the secure procedures used to distribute them.

5977 5978 5979

shall This term is used to indicate a requirement of a Federal Information Processing Standards (FIPS) publication or a requirement that must be fulfilled to claim conformance to this recommendation.

5980

Note: Shall may be combined with not to become shall not.

5981 5982 5983

shared secret A secret value that has been computed using a key-agreement scheme and is used as input to a key-derivation method. A shared secret from a key-agreement scheme cannot be used directly as a key.

5984 5985 5986

shared secret key A shared secret that can be used directly as a cryptographic key in symmetric-key cryptography. It does not require additional key derivation.

5987 5988 5989

should This term is used to indicate a very important recommendation. Ignoring the recommendation could result in undesirable results.

5990

Note: Should may be combined with not to become should not.

5991 5992

signature generation The use of a digital signature algorithm and a private key to generate a digital signature on data.

5993 5994 5995

signature verification The use of a digital signature algorithm and a public key to verify a digital signature on data. The digital signature was generated using the corresponding private key.

5996 5997 5998

source authentication The process of providing assurance about the source of information. Sometimes called “origin authentication.” Compare with identity authentication.

5999 6000 6001

split-knowledge procedure A procedure for establishing a key from multiple key shares, each of which is only known by a single entity. The key shares are combined using an approved method. See key share.

6002 6003 6004 6005 6006

sponsor (of a certificate) A human entity who is responsible for managing a certificate for the non-human entity identified as the subject in the certificate (e.g., a device, application, process). Certificate management includes applying for the certificate, generating the key pair, replacing the certificate when required, and revoking the certificate. A certificate sponsor is also a sponsor of the public key in the certificate and the corresponding private key.

184

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

6007 6008 6009

sponsor (of a key) A human entity who is responsible for managing a key for the non-human entity (e.g., organization, device, application, or process) that is authorized to use the key.

6010 6011 6012

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 an ephemeral key.

6013 6014

suspended state A key state in which the use of a key or key pair may be suspended for a period of time.

6015 6016 6017 6018

symmetric key A single cryptographic key that is used with a symmetric-key cryptographic algorithm, is uniquely associated with one or more entities, and is not made public (i.e., the key is kept secret). A symmetric key is often called a secret key. See secret key.

6019 6020 6021

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.

6022 6023 6024

system A discrete set of resources that are organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

6025 6026

system initialization A function in the life cycle of a cryptographic key. Setting up and configuring a system for secure operation.

6027 6028 6029 6030 6031

trust anchor 1. An authoritative entity for which trust is assumed. In a PKI, a trust anchor is a certification authority, which is represented by a certificate that is used to verify the signature on a certificate issued by that trust-anchor. The security of the validation process depends on the authenticity and integrity of the trust anchor’s certificate. Trust anchor certificates are often distributed as self-signed certificates.

6032

2. The self-signed public key certificate of a trusted CA.

6033 6034 6035 6036

trusted channel A trusted and safe communication link established between a cryptographic module and a sender or receiver to securely communicate unprotected plaintext, critical security parameters, key components, and authentication data.

6037 6038

unauthorized disclosure An event that involves the exposure of information to entities that are not authorized to access the information.

6039 6040

user An individual (person). Also see entity.

6041 6042 6043

X.509 certificate The X.509 public-key certificate or the X.509 attribute certificate, as defined by the ISO/ITU-T X.509 standard. Most commonly (including in this document), an X.509 certificate refers to the X.509 public-key certificate.

185

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

6044 6045

Recommendation for Key Management Part 1 — General

Appendix F. Change Log In 2025, the following changes were made to SP 800-57, Part 1:

6046 6047

1. The NIST template for this publication was changed, resulting in moving the acronyms and definitions (in Revision 5) from Section 2 to the appendices.

6048 6049

2. Ascon, as specified in SP 800-232, and the new quantum-resistant algorithms specified in FIPS 203, 204, and 205 have been included.

6050

3. Section 2.6: Text was added about destroying keying material.

6051 6052

4. Section 2.7: The description of key transport has been modified slightly, and a description of key encapsulation has been added.

6053 6054 6055

5. Section 3.1 (previously Section 4.1): The eXtendable-Output Functions (XOFs) specified in FIPS 202 have been included, and the term “hash method” is used to refer to both methods of hashing.

6056 6057

6. Section 3.3 (previously Section 4.3): The discussion on asymmetric-key algorithms was expanded.

6058 6059 6060 6061

7. Section 4.1.1 (old Section 5.1.1): Keys used for both key-establishment and key storage are now discussed separately. The encapsulation and decapsulation keys used in FIPS 203 have been included for both automated key-establishment and keystorage applications.

6062 6063

8. Section 4.3.4 (previously Section 5.3.4): An example for encapsulation/decapsulation keys was added.

6064 6065 6066 6067

9. Section 4.3.6 (previously Section 5.3.6): Keys used for key establishment and key storage are now discussed separately. The encapsulation and decapsulation keys used in FIPS 203 have been included for both automated key-establishment and keystorage applications.

6068 6069 6070 6071 6072 6073 6074

10. Section 4.6.1 (previously Section 5.6.1): The security categories used in the PQC competition have been included, along with the quantum-resistant algorithms (in Table 5). TDEA is now shown as disallowed, and Ascon-AEAD128 has been added (in Table 3). DSA is shown as disallowed (in Table 4). ML-KEM, ML-DSA, SKH-DSA, and the hash-based signature algorithms in SP 800-208 have been added to Table 5. Table 6 now includes Ascon-hash256, Ascon-XOF128, Ascon-CXOF128, SHAKE128, and SHAKE 256.

6075 6076

11. Section 4.6.2 (previously Section 5.6.2): The examples have been changed to use MLKEM and ML-DSA.

6077 6078

12. Section 4.6.3 (previously Section 5.6.3): The time frames have been removed and replaced with references to SP 800-131A.

6079 6080 6081

13. Section 4.6.4 (previously Section 5.6.4): This section has been updated to include additional guidance that was developed during the PQC transition and references to NIST’s crypt agility project. 186

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

Recommendation for Key Management Part 1 — General

6082 6083

14. Section 4.6.5 (previously Section 5.6.5): New text has been included about terminating the cryptoperiod when an algorithm is disallowed in SP 800-131A.

6084 6085 6086

15. Section 5.1.1 (previously Section 6.1.1): The encapsulation and decapsulation keys have been added, and communication and storage applications have been separated in the table (some changes were made to the last column of the table).

6087 6088 6089

16. Section 5.1.2 (previously Section 6.1.2): Changes have been made to the rightmost column in the table to include seeds used for (re)generating keys (e.g., ML-KEM key pairs).

6090 6091

17. Section 5.2.2 (previously Section 6.2.2): A subsection on key storage media (e.g., using HSMs and TPMs) has been added as Section 5.2.2.7.

6092 6093

18. Section 5.2.3 (previously Section 6.2.2): The seed used to (re)generate a key or key pair has been added to the list of possible metadata.

6094 6095

19. Section 5.2.2.7 (new): A section has been added to discuss keying material storage and mechanisms.

6096 6097 6098 6099 6100

20. Section 6 (previously Section 7): Encapsulation and decapsulation keys have been added. The deactivation state has been removed. A table has been added to the activation state to clarify transitions to the destroyed state (Section 6.2). Transitions from the compromised state to the destroyed state have been expanded for clarity (Section 6.3).

6101 6102

21. Section 7 (previously Section 8): The discussion of particular keys for each key state have been removed, leaving basic descriptions of the key states.

6103 6104

22. Section 7.1.5.2.3 (previously Section 8.1.5.2.3): A discussion of key encapsulation is now included with the discussion of key agreement.

6105 6106

23. Section 7.1.5.3.4 (previously Section 8.1.5.3.4): The discussion of seeds has been expanded to include seeds used for the (re)generation of keys (e.g., ML-KEM keys).

6107 6108 6109

24. The references have been updated, including adding references to FIPS 203, FIPS 204, FIPS 205, SP 800-208, ISO/IEC 19790, NIST IR 7977, SP 800-224, SP 800-227, and SP 800-232.

6110 6111 6112 6113

25. Appendix B was reorganized, placing the discussions about the key types at the end of the appendix and discussing the key types in the same order as used in the main body (e.g., in Section 4.1.1). Guidance for encapsulation/decapsulation key pairs was added as well as additional and/or clarifying guidance for many of the key types.

6114 6115 6116

26. Appendix C was added to address uncertainties in estimating the security strengths of post-quantum cryptosystems. The categorization approach is based on the range of security strengths offered by existing NIST standards in symmetric cryptography.

6117 6118

27. Appendix D (previously Section 2.2): New terms were added, including ML-DSA, MLKEM, PQC, SLH-DSA, and XOF.

187

NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025

6119 6120 6121 6122 6123 6124 6125 6126

Recommendation for Key Management Part 1 — General

28. Appendix E (previously Section 2.1): New definitions have been added, including “destroy (a key or other data),” “eXtendable-Output Function,” “hashing method,” “security categories”, “shared secret key,” “split-knowledge procedure,” and “trusted channel.” Modified definitions now include “assurance of validity,” “decapsulation,” “encapsulation,” “contingency planning,” “key-encapsulation mechanism,” “key wrapping,” “key-wrapping key,” “private key,” “public key,” “public key certificate,” “recipient-usage period,” “security strength,” and “seed.” The definition for “domain parameter” has been changed to “algorithm parameter.”

188

Related documents

• NIST SP 800-119: Guidelines for the Secure Deployment of IPv6#2864
• NIST SP 800-209r1 ipd: Security Guidelines for Storage Infrastructure#392298
• NIST SP 1800-41 ipd: Responding to and Recovering from a Cyber Attack: Cybersecurity for the Manufacturing Sector#213681
• NIST SP 800-230 ipd: Additional SLH-DSA Parameter Sets for Limited Signature Use Cases#5898
• NIST SP 800-46r2: Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security#3007