Every cryptographic system is only as strong as its key management. The most secure algorithm in existence is worthless if the key is stored in plaintext on a shared drive, never rotated, or generated from a predictable source. Key management is not a feature — it is the foundation.
A cryptographic key must be indistinguishable from random noise. That requirement flows down to two components: an entropy source and a cryptographically secure pseudorandom number generator (CSPRNG).
Entropy sources collect unpredictable physical events — interrupt timing, disk seek jitter, mouse movements, thermal noise from hardware random number generators (HRNGs). On Linux, /dev/urandom draws from the kernel’s entropy pool, which mixes hardware and OS event sources. On modern CPUs, the RDRAND instruction provides hardware-generated random numbers directly.
CSPRNGs take a small seed of true entropy and expand it into a long stream of pseudorandom bytes that pass all known statistical tests. The key distinction from a regular PRNG: a CSPRNG’s output is computationally indistinguishable from true randomness even to an attacker who has seen prior output.
The Debian OpenSSL disaster (2008) is the canonical example. A maintainer commented out two lines of code that fed process memory into the entropy pool because Valgrind flagged them as using uninitialized memory. The result: the CSPRNG was seeded only with the process ID — a 15-bit value. Every SSL key generated on affected Debian systems for nearly two years came from a pool of roughly 32,768 possible keys. The fix was trivial; the damage was catastrophic. Every key generated during that period had to be revoked and regenerated.
A key that exists in plaintext on disk is a key that will eventually be compromised. The spectrum of key storage solutions reflects different threat models:
Hardware Security Modules (HSMs) are dedicated hardware devices that generate, store, and use cryptographic keys without ever exposing the key material. The keys never leave the HSM boundary. Operations happen inside the device — data goes in, signatures or ciphertexts come back. FIPS 140-2 Level 3 HSMs have tamper-evident seals and will zeroize keys if physical tampering is detected. AWS CloudHSM and on-premises devices like Thales Luna are common examples.
Key Management Services (KMS) provide HSM-backed key management through an API. AWS KMS, Google Cloud KMS, and Azure Key Vault all store master keys in HSMs but expose a service API for encrypt/decrypt operations. The master key is never exposed — plaintext goes in, ciphertext comes back.
HashiCorp Vault occupies a different niche: it manages secrets (API keys, database credentials, certificates) alongside encryption keys. Vault can encrypt data with its transit secrets engine, generate dynamic database credentials, and manage PKI certificates. It supports multiple storage backends and unseals with Shamir’s Secret Sharing — splitting the master key into shares that must be combined to unlock the vault.
Linux Unified Key Setup (LUKS) manages full-disk encryption keys. The actual disk is encrypted with a master key, which is itself encrypted with a key derived from a passphrase via PBKDF2 or Argon2. LUKS supports up to 8 key slots — each slot can hold the master key encrypted with a different passphrase, enabling multiple users or recovery keys without re-encrypting the entire disk.
Keys have a lifecycle: generation, distribution, active use, rotation, and destruction. Rotation — replacing an active key with a new one — limits the damage from a compromise and reduces the amount of data encrypted under any single key.
Time-based rotation replaces keys on a fixed schedule regardless of usage. AWS KMS supports automatic annual rotation of customer master keys. The old key is retained for decryption but is no longer used for new encryptions.
Usage-based rotation replaces keys after encrypting a certain volume of data. AES-GCM has a practical limit of roughly 2^32 encryptions under the same key before nonce collision becomes likely with random nonces. Systems that encrypt at high volume must rotate before hitting that limit.
Compromise-driven rotation is an emergency response. When a key is suspected of being exposed, every artifact encrypted or signed with that key must be evaluated. Certificates are revoked. Encrypted data may need re-encryption with a new key. This is why key rotation should be automated and tested before it is needed in an emergency.
Rotating an encryption key means new data uses the new key, but what about existing data? Naive re-encryption reads all existing ciphertexts, decrypts with the old key, re-encrypts with the new key, and writes them back. For databases with terabytes of encrypted data, this is operationally expensive and creates a window where both keys must exist simultaneously. Envelope encryption (covered next) solves this problem elegantly.
Envelope encryption uses a hierarchy of keys to separate key management from data encryption:
Data Encryption Key (DEK): a unique, randomly generated symmetric key that encrypts a specific piece of data. Each file, database row, or message gets its own DEK.
Key Encryption Key (KEK): a master key (typically stored in an HSM or KMS) that encrypts the DEKs. The KEK never touches the data directly.
The process: generate a DEK, encrypt the data with the DEK, encrypt the DEK with the KEK, store the encrypted DEK alongside the encrypted data, and discard the plaintext DEK. To decrypt: retrieve the encrypted DEK, decrypt it with the KEK (via the KMS), then decrypt the data with the recovered DEK.
Why this matters: rotating the KEK only re-encrypts the DEKs — not the underlying data. For a million encrypted files, rotating the KEK means re-encrypting a million small DEKs, not re-encrypting a million files. The data never moves.
AWS KMS implements envelope encryption natively. A call to GenerateDataKey returns a plaintext DEK and a ciphertext DEK (the DEK encrypted by the KMS master key). The data is encrypted with the plaintext DEK, the ciphertext DEK is stored with the encrypted data, and the plaintext DEK is discarded. To decrypt, a call to Decrypt with the ciphertext DEK returns the plaintext DEK, which then decrypts the data. The master key never leaves the HSM. AWS encrypts EBS volumes, S3 objects, and RDS databases using exactly this pattern.
A system often needs multiple keys but has only one source of keying material. Key derivation functions (KDFs) deterministically produce one or more keys from input keying material.
HKDF (HMAC-based Key Derivation Function) takes input keying material (like a Diffie-Hellman shared secret), an optional salt, and context-specific info, and produces one or more output keys. TLS 1.3 uses HKDF to derive all session keys from the shared secret. The “info” parameter ensures that the same input produces different keys for different purposes — one for client-to-server encryption, another for server-to-client.
PBKDF2 (Password-Based Key Derivation Function 2) takes a password, a salt, and an iteration count, and produces a derived key. The high iteration count makes brute-force attacks expensive. PBKDF2 is used in LUKS, WPA2, and many password storage systems. Modern alternatives like Argon2 add memory-hardness — they require large amounts of RAM during derivation, making GPU-based attacks impractical.
A Diffie-Hellman shared secret has 256 bits of entropy. A typical user password has maybe 30 bits. HKDF assumes high-entropy input and does minimal work — it is fast by design. PBKDF2 and Argon2 assume low-entropy input and are deliberately slow, forcing attackers to spend significant time on each guess. Using HKDF to derive a key from a password would allow an attacker to try billions of passwords per second. Using PBKDF2 with 600,000 iterations (OWASP’s current recommendation) or Argon2id with appropriate memory parameters makes each guess computationally expensive.
This lesson establishes:
Next: WebAuthn and FIDO2