Design an envelope encryption system distinguishing DEK and KEK roles and responsibilities

Steps

1. Define the Data Encryption Key (DEK) as a symmetric key generated fresh per record or per data partition, used only to encrypt the payload, and never persisted in plaintext
2. Define the Key Encryption Key (KEK) as a long-lived key stored in a KMS or HSM; the KEK encrypts (wraps) the DEK so only the wrapped DEK ciphertext is stored alongside the payload
3. Choose DEK granularity based on your threat model: per-record DEKs limit blast radius if one ciphertext is compromised, while per-tenant DEKs simplify multi-tenant key isolation
4. Implement the encrypt path: generate DEK, encrypt payload with DEK, encrypt DEK with KEK, store (encrypted payload + wrapped DEK + KEK reference)
5. Implement the decrypt path: retrieve KEK reference, call KMS/HSM to unwrap DEK, decrypt payload with DEK, discard DEK from memory
6. Plan for KEK rotation: rotating the KEK requires rewrapping all stored wrapped DEKs with the new KEK; consider using key versioning to phase rotation without a single large rewrap job