up:: Migration Architecture MOC

NIST SP 800-57 (Key Management)

NIST SP 800-57 Part 1 is the NIST Special Publication titled “Recommendation for Key Management, Part 1, General,” the authoritative document for how cryptographic keys are sized, protected, and managed across their lifecycle. It carries three pieces of content the conceptual Key Management note leans on but doesn’t anchor to a standard: the concept of a cryptoperiod (the bounded time a key is authorized for use), the comparable-security-strength tables (which map a target security strength to the AES, RSA, and ECC key sizes that provide it), and the key-state lifecycle model (the defined states a key moves through from generation to destruction).

Those three are directly load-bearing for the quantum transition, because sizing harvest-now-decrypt-later exposure and running the Mosca inequality both depend on knowing a key’s cryptoperiod, its strength, and where it sits in its lifecycle.

The short version:

1. It’s NIST’s key-management standard, SP 800-57 Part 1 Rev. 5 (May 2020), and it’s the document behind the practices the conceptual Key Management note teaches.
2. A cryptoperiod is the bounded span of time a key is authorized for use, and it’s the concept that limits how much data one key protects and how long a compromise reaches.
3. The comparable-security-strength table maps a security strength (112, 128, 192, 256 bits) to the symmetric (AES) and asymmetric (RSA, ECC) key sizes that deliver it, so 128-bit strength is AES-128, RSA-3072, or a 256-bit elliptic curve.
4. The key-state model defines the six-state lifecycle a key moves through, pre-activation, active, suspended, deactivated, compromised, and destroyed, which is the framework an emergency rotation operates on.
5. The quantum transition uses all three: cryptoperiods and strengths feed HNDL and Mosca sizing, and the lifecycle model is where rotation and re-wrapping actually happen.

Think of a set of keys to a building the way a facilities manager does. Each key has a rating for how strong its lock is (the security strength), a period it’s valid before it must be re-cut (the cryptoperiod), and a status in a logbook, on order, issued and in use, suspended, reported stolen, or destroyed (the key states). A serious operation doesn’t just hand out keys; it tracks all three for every key, because that’s what lets it say how much a single stolen key exposes, how long until it’s replaced, and which locks share a rating. SP 800-57 is the standard that writes that facilities-management discipline down for cryptographic keys, and the quantum migration is a large-scale re-cutting exercise that needs exactly that ledger to plan against.

What is NIST SP 800-57 Part 1?

NIST SP 800-57 Part 1 is the general-guidance volume of NIST’s key-management recommendation, providing the framework, definitions, and best practices for managing cryptographic keying material through its whole lifecycle. Its identity, for citation:

1. Title: “Recommendation for Key Management, Part 1, General.”
2. Issuer: NIST (National Institute of Standards and Technology).
3. Status and date: Final, Revision 5, published May 2020 (superseding Revision 4 from 2016).
4. Role: The general framework. Part 1 covers the concepts (strengths, cryptoperiods, key states); companion parts cover organizational best practices (Part 2) and application-specific guidance (Part 3).

Source: NIST, “Recommendation for Key Management, Part 1, General,” SP 800-57 Part 1 Rev. 5, May 2020, SP 800-57 Part 1 Rev. 5.

The reason a migration reaches for this document specifically is that a post-quantum transition is a key-management program at heart. Deciding which keys are quantum-vulnerable, how long each protects data that must stay secret, and in what order to rotate them are all key-management questions, and SP 800-57 is the standard that gives those questions their vocabulary and their numbers.

What is a cryptoperiod, and why does it matter for HNDL?

A cryptoperiod is the span of time during which a specific key is authorized for use, after which it must be retired and replaced, and it matters for the quantum transition because it bounds how much data a single key protects and how long that data’s confidentiality has to survive. SP 800-57 recommends limiting cryptoperiods for concrete reasons: a shorter cryptoperiod limits the amount of information protected by one key, limits the exposure if a single key is compromised, and limits the time available to attack the key.

The connection to harvest-now-decrypt-later is direct. HNDL exposure depends on how long data must stay secret, and a key’s cryptoperiod interacts with that secrecy lifetime. Data encrypted under a key with a long cryptoperiod, or data whose confidentiality must outlast the key by years, is exactly the data a harvesting attacker records now to decrypt later. So a migration that inventories cryptoperiods alongside algorithms can see which keys protect long-lived secrets under quantum-vulnerable schemes, which is the intersection that makes a system urgent. The cryptoperiod is one of the inputs that turns a flat inventory into a prioritized queue.

Source: NIST SP 800-57 Part 1 Rev. 5, §5.3 (Cryptoperiods), May 2020, SP 800-57 Part 1 Rev. 5.

What are the comparable security strengths, and how do they map?

The comparable-security-strength table is SP 800-57’s mapping from a target security strength, expressed in bits, to the key sizes that provide that strength across symmetric, integer-factorization (RSA), finite-field, and elliptic-curve (ECC) algorithms, so a 128-bit security target has a specific AES, RSA, and ECC key size that all deliver it. This table is what lets you say a 3072-bit RSA key and a 256-bit elliptic curve are “the same strength” as AES-128, which is the reasoning behind every algorithm-and-key-size choice.

Security strength	Symmetric	RSA / integer-factorization modulus	ECC key size
112 bits	3-key Triple-DES (now deprecated)	2048 bits	224 to 255 bits
128 bits	AES-128	3072 bits	256 to 383 bits
192 bits	AES-192	7680 bits	384 to 511 bits
256 bits	AES-256	15360 bits	512+ bits

Source: NIST SP 800-57 Part 1 Rev. 5, Table 2 (Comparable security strengths of symmetric block cipher and asymmetric-key algorithms), May 2020, SP 800-57 Part 1 Rev. 5.

Two things about this table are load-bearing for the quantum transition:

1. It’s the classical yardstick. It shows why classical asymmetric keys are so much larger than symmetric ones for the same classical strength, a 128-bit symmetric key versus a 3072-bit RSA key, and that gap is a purely classical accounting that quantum computing upends entirely.
2. Its strength numbers describe classical attackers only. Shor’s algorithm collapses the RSA and ECC columns to near-zero regardless of key size, while Grover’s algorithm only halves the symmetric column, which is the whole reason the migration replaces the asymmetric algorithms and merely enlarges the symmetric key.

The NIST security levels used for the post-quantum standards are calibrated against this same table, so it’s the bridge between classical and post-quantum strength accounting.

What are the key states in the lifecycle?

The key-state model is SP 800-57’s definition of the phases a cryptographic key moves through from creation to destruction, and it’s the framework that makes key rotation, suspension, and emergency response precise operations rather than ad-hoc actions. A key is always in exactly one state, and the transitions between states are the events a key-management system tracks. The states:

1. Pre-activation. The key has been generated but is not yet authorized for use.
2. Active. The key is authorized and in use to protect or process information.
3. Suspended. The key’s use is temporarily suspended, for example pending investigation of a possible compromise or while a system is offline, and it can later return to active or move on to deactivation or destruction.
4. Deactivated. The key’s cryptoperiod has ended, so it stops applying new protection and is retained only to process information it already protected, for example to decrypt old data.
5. Compromised. The key is known or suspected to be exposed, so its use for protection stops and its prior use is treated as at risk.
6. Destroyed. The key material has been securely erased so it’s unrecoverable.

Source: NIST SP 800-57 Part 1 Rev. 5, §7 (Key States and Transitions), May 2020, SP 800-57 Part 1 Rev. 5.

The lifecycle is where a post-quantum migration physically happens. Rotating a quantum-vulnerable key to a post-quantum one is a sequence of state transitions, activate the new key, deactivate the old one, eventually destroy it, and an emergency rotation after an algorithm break is the compromised-state path run under a deadline. So the state model is the operational substrate the whole migration moves keys through, and re-wrapping data-encryption keys in a data-at-rest migration is a lifecycle operation on the wrapping key, not a rebuild of the data.

How does SP 800-57 support quantum-risk sizing?

It supplies the three quantities the risk math needs: how long a key protects data (cryptoperiod), how strong it is and against what (comparable strengths), and where it is in its life (key state). Mosca’s inequality asks whether the years your data must stay secret plus the years your migration takes exceed the years until a quantum computer arrives, and the first term of that inequality is a cryptoperiod-and-secrecy-lifetime question that SP 800-57 frames. HNDL prioritization asks which keys protect long-lived secrets under quantum-vulnerable algorithms, which is a join of the strength table (is this algorithm quantum-vulnerable) and the cryptoperiod (how long does its data live). And the key-state model is what a rotation plan sequences against.

So SP 800-57 isn’t a post-quantum document, and it’s foundational to the post-quantum program anyway, because the transition is a key-management exercise conducted at scale. When a migration needs to defend a prioritization to a board or a regulator, the vocabulary of cryptoperiods, comparable strengths, and key states is what makes the reasoning standards-grounded rather than improvised, which is why the conceptual Key Management note points here for the authoritative anchor.

Common misconceptions

1. “SP 800-57 is about post-quantum cryptography.” It’s the general classical key-management standard, and it predates the PQC standards. It matters for the transition because a migration is a key-management program, so its cryptoperiods, strength tables, and key states are the framework the migration runs on.
2. “The comparable-strength table means RSA-3072 is safe because it equals AES-128.” That equivalence is classical only. Shor’s algorithm breaks RSA and ECC at any key size, so the asymmetric columns collapse under a quantum computer while the symmetric column only halves, which is the whole reason for the migration.
3. “A cryptoperiod is just a certificate expiry date.” It’s broader, the whole authorized-use span of a key, which limits how much data one key protects and how long a compromise reaches. It’s an input to HNDL and Mosca sizing, which reaches well beyond a renewal trigger.
4. “Once a key’s cryptoperiod ends, it’s destroyed.” It usually moves to the deactivated state first, retained to decrypt data it previously protected, and is destroyed only later. The key-state model separates “no longer used for new protection” from “erased.”
5. “Key management is a footnote to the algorithm choice.” It’s most of the migration. Choosing ML-KEM is the easy part; rotating keys through their lifecycle, sizing cryptoperiods, and re-wrapping under new strengths across a whole estate is the work SP 800-57 governs.

Questions people ask

What is NIST SP 800-57? It’s NIST’s “Recommendation for Key Management,” and Part 1 Rev. 5 (May 2020) is the general framework, covering cryptoperiods, comparable security strengths, and the key-state lifecycle. It’s the standard behind the practices the conceptual Key Management note teaches.

What is a cryptoperiod? It’s the bounded span of time a key is authorized for use, after which it’s retired. SP 800-57 recommends limiting it to cap how much data one key protects, how far a compromise reaches, and how long an attacker has, all of which feed HNDL sizing.

What key size equals 128-bit security? Per SP 800-57’s comparable-strength table, 128-bit security is provided by AES-128, a 3072-bit RSA modulus, or a 256-to-383-bit elliptic curve. That equivalence holds against classical attackers, and a quantum computer breaks the RSA and ECC entries regardless of size.

What are the key states? Pre-activation, active, suspended, deactivated, compromised, and destroyed, the six states defined in Part 1 Rev. 5. A key is always in exactly one state, and rotating to a post-quantum algorithm or running an emergency rotation is a defined sequence of transitions through those states.

Is SP 800-57 relevant to a quantum migration? Directly. A migration is a key-management exercise, so its cryptoperiods, strength tables, and key states are the framework for sizing HNDL exposure, running Mosca’s inequality, and sequencing rotations. It’s the standards anchor under the whole program.

Does it tell me which algorithm to migrate to? Not by itself, that’s FIPS 203 and the other post-quantum standards. SP 800-57 tells you how to manage the keys for whichever algorithm you choose, and its strength table is the yardstick the post-quantum security levels are calibrated against.

Why is AES only halved by a quantum computer but RSA broken? Because they rest on different problems. Grover’s algorithm gives only a square-root speedup against symmetric search, halving effective strength, while Shor’s algorithm solves the factoring and discrete-log problems RSA and ECC rest on, so the asymmetric columns of the strength table collapse.

---

Everything here is the map, given freely. When your team needs its keys inventoried with cryptoperiods and strengths, its quantum-vulnerable long-lived keys prioritized, and its rotations sequenced through the lifecycle onto post-quantum algorithms, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-14 · Maintained by Addie LaMarr, LaMarr Labs.