Key Management Basics

AES has not been broken in 25 years. The same cannot be said for the systems that hold AES keys. The vast majority of real-world cryptographic failures happen not in the algorithm but in the surrounding plumbing.

Every symmetric cipher assumes the key is secret, random, and known only to the parties who need it. Every one of those three properties is something an engineer has to actively enforce. A key written to a config file, checked into Git, mailed in plaintext, or generated from the system clock fails the assumption before AES even runs.

Key management is the discipline of answering five questions for every key in a system:

1. How was it generated, and is the source of randomness trustworthy?
2. How is it distributed to the parties that need it?
3. Where is it stored while in use, and who can read it?
4. When and how is it rotated or revoked?
5. How is it destroyed when it is no longer needed?

Every modern compliance framework (FIPS 140-3, PCI DSS, HIPAA, SOC 2, NIST SP 800-57) is, at its core, a checklist for these five questions.

A symmetric key is just a string of random bits. AES-128 needs 128 of them, AES-256 needs 256. The hard part is the word random.

Keys must come from a cryptographically secure pseudo-random number generator (CSPRNG). The operating system provides one. On Linux it is /dev/urandom or the getrandom() syscall. On Windows it is BCryptGenRandom. Most language standard libraries wrap these: Python secrets.token_bytes(32), Go crypto/rand, Node crypto.randomBytes(32).

What never works:

• The non-cryptographic RNG built into most languages (Python random, Java Math.random, C rand()). These are predictable.
• Hashing a timestamp, a username, or anything else with low entropy.
• Asking the user to type the key, unless that string is then fed through a proper key derivation function (see next section).

Users do not pick 256-bit random keys. They pick passwords. The job of a key derivation function (KDF) is to convert a low-entropy human password into a high-entropy, fixed-length symmetric key.

A KDF takes three inputs: the password, a salt (random bytes stored alongside the output), and a cost parameter that controls how expensive the derivation is. The expense is the point. If deriving a key takes 100 milliseconds for a legitimate user, it also takes 100 milliseconds for an attacker testing each password from a dictionary.

Argon2id is the default to reach for in any new system. PBKDF2 still appears in protocols (WPA2, TLS 1.2, many disk encryption tools) because it predates the others and is built into countless standards.

Once a key exists, the question becomes where to put it. The wrong answers are obvious in retrospect and embarrassingly common in practice.

The right answers all share a property: the key is held in a place that exposes only the operations you can perform with it, never the bytes themselves.

For a typical application: cloud KMS holds the root key, the secrets manager holds the day-to-day credentials, and individual disk volumes use TPM-sealed keys. No human reads any of those bytes directly.

Every key goes through the same six phases from creation to destruction. NIST SP 800-57 formalizes them; the diagram below shows the practical version.

A system encrypting a million files does not use one key for all of them, and it does not put a million keys in the HSM. It uses a hierarchy.

The pattern is called envelope encryption. One master key, the Key Encryption Key (KEK), lives in the HSM or KMS and never leaves. It is used only to encrypt other keys. The keys it encrypts are called Data Encryption Keys (DEKs), and the DEKs are the ones that actually encrypt user data.

The payoff is enormous:

• Rotation is cheap. To rotate, you re-wrap each DEK under the new KEK. The actual user data is never re-encrypted.
• Scale is unbounded. The HSM only ever sees the small KEK and tiny DEK wrap or unwrap calls. The DEKs do the heavy lifting elsewhere.
• Blast radius is limited. A leaked DEK exposes only the data it protected, not the whole system.
• Compliance is auditable. The HSM logs every KEK operation. That log is the audit trail.

AWS S3 server-side encryption, Google Drive, Apple FileVault, and almost every modern database encryption feature use this pattern. When AWS says "encryption is on by default," what they mean is that a KEK in KMS is wrapping per-object DEKs.

Rotating a key means generating a new one and shifting future operations to it. The old key sticks around long enough to decrypt anything it previously encrypted, then is destroyed.

Why rotate at all?

• Limit blast radius. If a key leaks, only the data encrypted during that key's active window is exposed.
• Limit ciphertext volume per key. AES-GCM, for example, has a hard limit of about 2³² messages per key before nonce-reuse becomes statistically likely.
• Compliance. PCI DSS requires at least annual rotation of cryptographic keys, and immediate rotation on suspected compromise.
• Personnel change. When someone with access to a key leaves the team, the key rotates.

Modern KMS systems automate this. AWS KMS supports automatic annual rotation of customer master keys. The application code does not need to know the rotation happened; the KMS keeps both versions and uses the appropriate one based on the encryption context tag baked into the ciphertext.

The abstract lifecycle becomes concrete in a few well-known places. Each of these is worth being able to picture when you read the term.