Key Management in Practice

Every primitive this course has covered — AES (Ch.5), hashing (Ch.7), MACs (Ch.8), RSA/DH/ECC (Ch.9), signatures (Ch.10) — is only as strong as the keys behind it. This chapter is the full payoff of the throughline first named in Chapter 1 and demonstrated concretely in Chapter 4's Enigma breakdown: real cryptographic failures are almost always about key management, not the underlying mathematics.

Entropy — Where Keys Actually Come From

A cryptographic key needs to come from a source of genuine entropy — true unpredictability, not merely output that "looks random." A cryptographically secure pseudorandom number generator (CSPRNG), properly seeded from an operating system's real entropy sources (hardware noise, timing jitter, and similar unpredictable physical inputs), is the correct tool. A pseudorandom number generator built for simulations, games, or statistical sampling — even one that passes ordinary randomness tests — is a completely different, unsuitable tool: such generators are typically deterministic and predictable once their internal state or seed is known, which is exactly what a cryptographic attacker needs.

Key Storage — Where Keys Live Once Generated

Keys should never be committed directly into source code or version control — a rule this site's own pipelines1-5 states plainly: a committed credential is compromised forever, since version history retains it indefinitely even after deletion. Environment variables are a step up but still leave keys sitting in plaintext in process memory and configuration. The modern standard is a dedicated secrets manager (a cloud provider's KMS, or a tool like Vault) — purpose-built for storing, retrieving, and auditing access to sensitive key material, with the keys themselves encrypted at rest, echoing dbsec1-5's encryption-at-rest coverage applied specifically to key material rather than application data.

Hardware Security Modules (HSMs)

An HSM is a dedicated, tamper-resistant hardware device that generates and stores private keys such that they never leave the device in plaintext form at all. Rather than retrieving a key to use it elsewhere, cryptographic operations — signing, decryption — are performed inside the HSM itself; only the input and the result cross the boundary, never the raw key material. This is a categorically different security model from software-only storage: even a fully compromised host system, with complete access to its own memory and disk, still cannot extract the private key — it can only request operations using it, and only for as long as it retains legitimate access to do so. HSMs are standard for root CA private keys (Chapter 10), banking infrastructure, and as the backend for most cloud KMS offerings.

Key Rotation

Keys shouldn't live forever. Regular rotation limits the blast radius of an undetected compromise (an old, retired key is useless to an attacker even if it was silently stolen), reduces how much data any single key ever protects, and forces regular verification that key-management processes actually work end to end, rather than being untested until an emergency. Rotation is easy to state and genuinely hard to execute well — replacing a key used by many dependent systems or services requires careful coordination, echoing the real complexity behind TLS certificate revocation.

Key Derivation — One Master Key, Many Purposes

Rather than independently generating and managing a large number of separate keys, real systems often derive several purpose-specific keys from one master secret, using a key derivation function (KDF). HKDF, a standard example, is built internally using HMAC (Chapter 8) — a direct callback to the exact primitive that chapter established. This reduces how much raw entropy needs to be generated and carefully managed directly, while still keeping keys used for different purposes (encryption, authentication, and so on) cryptographically separated from one another.

The Human Side — Access Control & the Principle of Least Privilege

dbsec1-3's least-privilege account design applies directly to keys themselves — not every service or person needs access to every key a system uses. For especially high-value keys (a root CA key, for instance), real systems sometimes use dual control or split-knowledge schemes, requiring several independent custodians to jointly participate before a key can be used or reconstructed at all — the same principle underlying real root CA key ceremonies and much cryptocurrency custody today.

What Actually Breaks Key Management in Practice

Looking back across this entire course, nearly every "real-world" failure this course has covered was a key-management failure, not a mathematical one:

• Chapter 4 — Enigma's "cillies" (predictable settings) and message-key reuse.
• Chapter 5 — a reused stream-cipher key/nonce, reintroducing the two-time-pad vulnerability.
• Chapter 6 — a reused CBC initialization vector, leaking whether two messages start identically.
• Chapter 9 — a compromised static (non-ephemeral) private key retroactively exposing every past session that used it.
• Chapter 10 — Sony's 2010 ECDSA nonce reuse, directly leaking a signing private key.
• This chapter — the 2008 Debian OpenSSL entropy disaster, making entire classes of keys exhaustively guessable from the moment of generation.

Hands-On Exercises