Encryption rarely fails because someone breaks AES. It fails because the key sat in a configuration file pushed to a public code repository, or was stored on the same server as the data it protected, or existed in exactly one place that was then lost. An attacker who can't break the cipher goes after the key instead.
On the CompTIA Security+ SY0-801 exam, cryptographic tools and key handling sit under objective 1.3, which expects you to pick the right cryptographic solution for a job. This lesson covers the key life cycle and the hardware and services built to protect keys: the TPM, the HSM, key management systems and secure enclaves.
Encryption is only as strong as the protection on its keys
Every key passes through the same life cycle: generation, distribution, storage, use, rotation, backup and recovery, and finally destruction. NIST SP 800-57 is the standard reference for managing that life cycle, and most organizational key management policies follow it.
Most real failures happen outside the algorithm. A developer hardcodes an encryption key in source code. A backup script writes the database key into the same storage bucket as the encrypted backups. A shared key is never changed after the people who knew it leave. In each case the encryption works perfectly and protects nothing, because the attacker who gets the data gets the key too.
Three principles guide the controls in this lesson. Keep keys separate from the data they protect. Limit who and what can use a key, and log every use. And plan for loss as carefully as for theft, because a lost key makes the data as unavailable as if it had been deleted.
Keys must come from a strong source of randomness
A key is only as unpredictable as the process that made it. Keys must come from a cryptographically secure pseudorandom number generator (CSPRNG), such as the operating system's generator behind /dev/urandom on Linux or the Windows cryptography APIs. General-purpose random functions, timestamps and counters are predictable and must never be used.
The classic failure is the Debian OpenSSL bug disclosed in 2008. A code change made in 2006 left the process ID as almost the only source of randomness, so affected systems could generate only about 32,768 possible keys for a given key type, size and processor architecture. Every SSH and TLS key created on those systems had to be replaced.
When a key has to come from a password, it must pass through a key derivation function such as PBKDF2, bcrypt, scrypt or Argon2, which adds a salt and makes each guess deliberately slow. Salting is covered in the hashing and salting section. Typical generation commands look like this:
$ openssl rand -hex 32
$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out server.key
$ ssh-keygen -t ed25519 -C "admin@jumpbox01"
The first produces a random 256-bit symmetric key, the second a 3072-bit RSA private key, and the third an Ed25519 SSH key pair. Key length guidance follows the earlier lessons: AES-128 at minimum and AES-256 for long-lived or high-value data, RSA 2048 at minimum and 3072 or more for keys used past 2030, and elliptic curves such as P-256, P-384 or Curve25519.