Encryption, Key Management, and Cryptography
What this domain tests
The exam tests practical cryptographic choices and, more heavily, the key lifecycle, because most real-world failures are key failures rather than algorithm failures. Expect questions on which primitive fits which job, and on what makes an encryption claim defensible.
Core rules
- Symmetric. AES-128 or AES-256 with an authenticated mode such as GCM. Never ECB. Never reuse a nonce with the same key.
- Asymmetric. RSA of at least 2048 bits, or ECC such as P-256, for key wrapping and signatures rather than bulk data.
- Hashing. SHA-256/384 for integrity. Passwords need a salted, memory-hard KDF: Argon2id, scrypt, bcrypt or PBKDF2, never a bare hash.
- Transport. TLS 1.2 minimum, TLS 1.3 preferred, ECDHE for forward secrecy, HSTS, and a managed certificate lifecycle.
- Key lifecycle. Generate inside a FIPS 140-2/3 validated module or HSM; separate duties so no one person controls keys; rotate and version; support recovery or escrow; destroy with evidence, including crypto-shredding by deleting the key.
- Envelope encryption. A data encryption key (DEK) encrypts the data, a key encryption key (KEK) in the KMS encrypts the DEK. Rotating the KEK does not require re-encrypting the corpus, and KMS access policy becomes the controlling permission.
- Agility and PQC. Do not hard-code algorithms; plan migration to NIST post-quantum standards such as ML-KEM and ML-DSA.
Worked example
A team wants both laptop protection and database field encryption. Full-disk encryption with escrowed recovery keys protects the device; database fields use envelope encryption. On an erasure request, deleting the subject's DEK renders the ciphertext unreadable (crypto-shredding) and the deletion is logged. Rotation is performed at the KEK layer without touching the data. Reasoning: name the threat model for each layer, then show how key custody makes the control real.
Traps that cost marks
Confusing hashing with encryption; believing encrypted data falls outside data protection law (it remains personal data); storing keys alongside ciphertext; reusing IVs or nonces; assuming TLS protects data at rest; claiming strong encryption when key access is unrestricted and unaudited.