Key Management & Lifecycle

Every other entry in this domain assumes a key exists, is unpredictable, is known only to the right parties, and can be replaced. Nothing provides that — key management does, and it is where cryptographic deployments actually fail. Schneier's framing in Applied Cryptography remains exactly right thirty years on: the algorithms are the easy part, and key management is "the hardest part of cryptography" because it is where mathematics meets operations, backups, staff turnover and disaster recovery.

The lifecycle #

flowchart LR
  G["Generate"] --> D["Distribute"] --> U["Use"] --> R["Rotate"] --> A["Archive"] --> X["Destroy"]
  U --> C["Compromise?"] --> RV["Revoke + re-key"]

Each stage has its own failure mode, and NIST SP 800-57 assigns each a distinct cryptoperiod — the time a key may be used.

Generate #

Keys come from a CSPRNG or are derived from one via a KDF. The failure here is upstream: an unseeded pool at first boot produced 64,000 factorable TLS keys in the 2012 internet-wide scan. Generate inside the security boundary that will hold the key — an HSM generates and never exports — rather than generating elsewhere and importing.

The key hierarchy, and envelope encryption #

Never encrypt bulk data directly with a long-lived key. The standard structure has three tiers:

Schneier's chapter 8 already reasons this way about session keys versus key-encryption keys, and the argument has not changed: the tradeoff is between the risk of reusing one key and the risk of distributing a new one.

Store #

The distinction that matters: an HSM or KMS is an oracle, not a store — you send data and get an operation performed; the key never exists outside the boundary. A secrets manager hands you the secret, which is appropriate for credentials you must present verbatim and inappropriate for a signing key. FIPS 140-3 levels describe the physical tamper-resistance of that boundary.

Rotate #

Rotation limits how much data one key protects and bounds the damage window of an undetected compromise. Schneier's reasons still hold in full: longer use means more chance of compromise, more loss when it happens, more incentive to attack it, and more ciphertext for cryptanalysis.

• Session keys — per connection or per message; TLS 1.3 can additionally ratchet within a connection via KeyUpdate.
• Data keys — per object.
• KEKs — months. Rotating a KEK means re-wrapping data keys, not re-encrypting data.
• Root keys — years, with a planned ceremony.
• Usage-bounded rotation matters too: AES-GCM with random 96-bit nonces has a birthday bound around $2^{32}$ messages per key. Rotate on volume, not only on time.

Key length, security strength, and cryptoperiod are different #

Key length is an encoding size; security strength is the approximate work factor of the best known attack. Equal-length keys from different families are not comparable because their attacks scale differently. NIST SP 800-57 Part 1 Rev. 5 gives these classical equivalences:

These are strength mappings, not instructions to keep a key forever. A cryptoperiod bounds when a key may protect or process data based on exposure, data lifetime, usage volume, recovery needs, and algorithm transitions. A 256-bit key can still need immediate rotation after compromise, and a short-lived session key can be correct even when the long-term authentication key lasts years.

Sites such as Keylength.com are useful calculators for comparing published recommendations, but the cited standard and its date are the decision authority. Also distinguish symmetric strength from the post-quantum picture: Grover changes exhaustive-search scaling, while Shor breaks RSA, finite-field DH, and ECC structurally rather than merely reducing their bit strength.

Archive and destroy #

Archiving and destruction pull in opposite directions and the tension is real: encrypted data that must remain readable for seven years needs its key kept for seven years, while a key that must be provably gone cannot be kept at all.

Crypto-shredding resolves it in one direction — destroy the key and the ciphertext is unrecoverable, which is how per-user data deletion is implemented at scale for GDPR-style erasure: give each user their own data key, delete that key, and their data is gone from every backup and replica at once without touching the backups.

Destruction has to account for the copies: memory (zero it; beware garbage-collected languages that move buffers, and swap), backups, HSM key slots, and any escrow.

Compromise #

Assume it will happen and write the runbook before it does. Schneier's chapter 8 treats compromised keys as a first-class scenario rather than an exception, and the modern sequence is:

1. Revoke — mark the key invalid everywhere; for certificates see the revocation limitations, which is why short lifetimes beat revocation.
2. Re-key — issue replacements and roll them out.
3. Assess the blast radius — what did this key protect, and for how long. Without forward secrecy, a compromised long-term key decrypts recorded past traffic; with ephemeral key agreement it does not. This is the single strongest operational argument for PFS.
4. Re-encrypt anything still protected by the compromised key.
5. Find the leak path — a rotated key in the same broken pipeline leaks again.

A practical baseline #

Use a managed KMS with envelope encryption rather than handling raw keys. Generate inside the boundary. Give every key an ID, a purpose, and a documented cryptoperiod. Never commit keys, never log them, never share across environments. Support the current and previous key simultaneously. Keep an inventory — most organizations cannot answer "which systems use which keys, and where do those keys live", and that question is also the prerequisite for the post-quantum migration.