Suppose you have a million records to encrypt and one secret key to do it with. The naive approach is to encrypt every record directly with that key. It works on day one. Then someone asks the questions that always come: how do you rotate the key without decrypting and re-encrypting all million records? How do you keep the key out of the application server's memory? How do you give one service access to decrypt records without handing it the key that decrypts everything?
Envelope encryption is the standard answer. Instead of using one key for the data, you use two layers: a data encryption key (DEK) that actually encrypts the bytes, and a key encryption key (KEK) that encrypts the DEK. The encrypted DEK travels with the ciphertext. The KEK stays somewhere guarded and never touches the data itself.
The Mechanics
The flow is short. To encrypt an object:
- Generate a fresh, random DEK (typically a 256-bit AES key).
- Encrypt the plaintext with the DEK using an authenticated cipher such as AES-GCM.
- Encrypt the DEK with the KEK. The result is the "wrapped" or "encrypted" DEK.
- Store the ciphertext and the wrapped DEK together. Discard the plaintext DEK from memory.
To decrypt, you reverse it: send the wrapped DEK to whatever holds the KEK, get back the plaintext DEK, decrypt the object, then throw the DEK away again. The plaintext DEK exists only for the moment of the operation.
The "envelope" is the wrapped DEK sitting next to the ciphertext. You can hand someone the sealed envelope all day long; it is useless without the KEK that opens it. The data and its locked key travel together, but the master key that unlocks everything stays home.
Why Two Keys Beat One
The indirection earns its keep in four places.
Key rotation becomes cheap
Rotating the KEK does not require touching the encrypted data at all. You decrypt each wrapped DEK with the old KEK and re-encrypt it with the new one. The DEKs are tiny (a few dozen bytes each) compared to the data they protect. Rotating a KEK across a million objects means re-wrapping a million small keys, not re-encrypting a million large records. This is the difference between a background job that finishes in minutes and one that runs for days and saturates your storage bandwidth.
The master key stays isolated
The KEK can live in a hardware security module or a managed key service and never leave it. The application asks the service to wrap or unwrap a DEK; the KEK material itself never enters application memory, never lands in a core dump, never shows up in a swapped-out page. A memory-scraping attack on the app server yields, at worst, a single DEK for a single in-flight operation, not the key to the entire dataset.
Per-object keys limit blast radius
Because each object gets its own DEK, compromising one DEK exposes exactly one object. There is no single key whose leak unlocks the whole store. This is the same principle behind forward secrecy in transport protocols, applied to storage: you want the compromise of one key to be a small, bounded event.
Access control moves to the KEK
Permission to read data becomes permission to call "unwrap this DEK." You can log every unwrap, rate-limit it, require additional context, or revoke it, all without moving any data. The audit trail lives at the key service, and revoking access is as simple as removing a principal's ability to use the KEK.
Where It Shows Up
Once you know the pattern, you see it everywhere. Cloud key-management services (AWS KMS, Google Cloud KMS, Azure Key Vault) are built around it: they hold your KEK, and their SDKs generate DEKs, hand you the plaintext DEK to use locally, and return the wrapped version to store. Encrypted database features, transparent disk encryption, and backup tools use the same layering. PGP itself is envelope encryption in spirit: a message is encrypted with a random session key, and that session key is encrypted to each recipient's public key.
| Layer | What it encrypts | Where it lives |
|---|---|---|
| DEK (data key) | The actual object, with AES-GCM or similar | Wrapped, stored next to the ciphertext; plaintext form is memory-only and short-lived |
| KEK (key-wrapping key) | The DEKs, nothing else | HSM or managed key service; never touches the data |
| Root / master | The KEKs, in deep hierarchies | The most guarded tier, often hardware-backed and rarely used directly |
Larger systems add more layers: a root key wraps regional KEKs, which wrap per-tenant KEKs, which wrap per-object DEKs. Each layer narrows what a single compromised key can reach. The shape is always the same, just nested.
The Sharp Edges
Envelope encryption solves key management. It does not solve trust, and confusing the two is the common mistake.
The KEK holder is the real boundary. If your KEK lives in a managed cloud service, that provider can technically unwrap your DEKs, which means they can decrypt your data if compelled or compromised. Envelope encryption gives you operational hygiene and clean access control; it does not, by itself, make the data unreadable to the party holding the KEK. If your threat model includes the key service operator, the KEK has to be one you alone control, derived or stored client-side.
"Who can unwrap the DEK?" answers "who can read the data." Every envelope-encryption design lives or dies on that one boundary. If the answer includes a party you do not trust with the plaintext, the encryption is protecting you from everyone except the one entity that matters.
The other failure modes are mundane and therefore common. A DEK must be generated from a cryptographically secure random source; a predictable DEK voids the whole scheme. The plaintext DEK must be wiped from memory promptly after use. And the wrapping itself should be authenticated, so that a tampered wrapped DEK fails loudly instead of unwrapping to garbage that gets used anyway.
How Haven Thinks About It
Haven's architecture follows the same instinct, with the trust boundary deliberately moved to the client. Your passphrase derives keys on your device; the keys that protect your content are never sent to our servers, not even as a hash of themselves. We can hold ciphertext without holding the means to read it, because the unwrapping happens on hardware you control, not on ours.
That is the honest version of what envelope encryption can and cannot do. It is an excellent tool for managing keys at scale and limiting damage when one key leaks. Whether it protects you from a given adversary is entirely a question of who holds the key that opens the envelope. If you want to go deeper, our pieces on hardware security modules and key derivation with HKDF cover the two ends of the chain.