The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Envelope encryption protects data with two keys: a short-lived data encryption key (DEK) encrypts the payload, while a centrally managed key encryption key (KEK) wraps that DEK. The encrypted payload and wrapped DEK can travel together, but the KEK remains inside a key-management service (KMS). This lets applications encrypt large files locally while retaining centralized authorization, audit, and rotation for the keys that control access.
What envelope encryption means
Google Cloud defines the pattern plainly: “The process of encrypting a key with another key is known as envelope encryption.” The inner key is the DEK. It performs the high-volume encryption and decryption of your object, database record, message, or backup. The outer key is the KEK. It encrypts, or wraps, the DEK so that a stored copy of the DEK is useless without authorization to unwrap it.
A typical envelope therefore contains four kinds of information: ciphertext, a wrapped DEK, the identity or version of the KEK, and the authenticated-encryption metadata needed to process the ciphertext. The KEK itself is not placed beside the data. A KMS, hardware-backed key manager, or equivalent service retains it and enforces policy when a workload requests a wrap or unwrap operation.
| Component | Primary job | Usual handling | If exposed |
|---|---|---|---|
| Data encryption key (DEK) | Encrypts and decrypts the actual payload | Generated for the required scope, used briefly in plaintext, then discarded; only its wrapped form is stored | The attacker can decrypt the data protected by that DEK |
| Key encryption key (KEK) | Wraps and unwraps DEKs | Held inside KMS with access controls, audit logs, and versioning | Unauthorized wrapping or unwrapping could affect every DEK governed by that KEK |
| Wrapped DEK | Stores the DEK safely with the ciphertext | Persisted as encrypted bytes and retrieved when needed | Not useful by itself; KMS authorization is still required |
Keeping these roles separate is the design’s central security boundary. A storage administrator may see ciphertext and wrapped keys without receiving the KEK. A KMS administrator can control key policy and rotation without handling application data. Neither separation removes the need to secure application identities, memory, logs, or the encryption metadata.
#1 Best Overall
Why not encrypt an entire file directly with KMS?
KMS APIs are designed for protected key operations, not for streaming every byte of a large object. Google Cloud documents a maximum input size of 64 KiB for Cloud KMS Encrypt and Decrypt. Sending a multi-megabyte or multi-gigabyte file through such an API would also add latency, network transfer, service quotas, and avoidable cost.
Envelope encryption keeps bulk cryptography local. A workload performs one fast symmetric encryption pass over the payload, then asks KMS to process only the small DEK. During decryption, it retrieves the wrapped DEK, performs an authorized unwrap, and decrypts the payload locally. The number of KMS operations is tied to the number of DEKs rather than the number of bytes, so the architecture scales when objects are large or numerous.
The split also narrows the administrative surface. You can grant a service permission to use a specific KEK without granting it permission to read every storage location. KMS can record wrap and unwrap requests, enforce conditional policies, and advance KEK versions while applications continue to use locally generated DEKs.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →How the envelope-encryption flow works
-
Generate a fresh DEK
The workload creates a cryptographically random symmetric DEK locally, using a trusted operating-system or cryptographic library random source. Choose the scope deliberately: one DEK per object is easy to reason about, while a record or message may justify its own DEK when isolation is more important than KMS-call reduction. Do not persist the plaintext DEK.
-
Encrypt the payload locally
Use authenticated encryption, such as 256-bit AES-GCM, which Google recommends for this use case. Generate a unique nonce (also called an IV) for every encryption under that DEK. Include selected context, such as an object identifier, tenant identifier, or format version, as authenticated additional data when your protocol requires it. The result is ciphertext plus an authentication tag; tampering must cause decryption to fail.
-
Wrap the DEK with the KEK
Send the plaintext DEK to the KMS wrapping operation over the authenticated service connection. KMS uses the selected KEK version and returns wrapped key bytes. The KEK never leaves the KMS boundary. Minimize the time the plaintext DEK remains in process memory and prevent it from entering request logs, traces, crash dumps, or exception messages.
-
Store the envelope
Persist the ciphertext and wrapped DEK together or in consistently addressable records. Store the algorithm identifier, nonce or IV, authentication tag (if not embedded by the format), a format version, and the KEK identifier or version needed for unwrapping. Treat these fields as security metadata: if they are altered, authenticated decryption should reject the data or the service should detect the mismatch before attempting decryption.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Authorize and unwrap during decryption
When a reader requests the object, fetch the envelope metadata and verify that the caller is allowed to access it. Ask KMS to unwrap the DEK, supplying the recorded KEK identifier and any required encryption context. KMS returns the plaintext DEK only to an authorized principal. A failed authorization, disabled key version, or unavailable KMS should produce a controlled error rather than a fallback to an unprotected key.
-
Decrypt, authenticate, and erase
Use the unwrapped DEK and stored nonce, tag, and authenticated data to decrypt locally. Authentication must succeed before the application releases plaintext to the caller. Erase or otherwise make the plaintext DEK unreachable as soon as the operation finishes; also review language-runtime behavior, swap, core dumps, and memory snapshots because ordinary garbage collection does not guarantee immediate removal.
DEK and KEK: the practical difference
The DEK is close to the data and optimized for speed. The KEK is close to governance and optimized for control. A single KEK can protect many wrapped DEKs, but that does not mean every object shares the same plaintext key. Compromise of one DEK should be limited to the objects or messages assigned to it; compromise of a KEK is a much broader event that requires incident response, policy review, and potentially rewrapping large populations of DEKs.
How major cloud implementations apply the pattern
The cryptographic split is consistent across providers, while API behavior, caching, metadata formats, and operational controls differ.
| Implementation | DEK generation and use | KEK location and control | Notable operational detail |
|---|---|---|---|
| Google Cloud KMS with Tink | Tink generates a DEK, encrypts data locally, and combines the encrypted data with the wrapped DEK in its ciphertext output. Google lists Python, Java, C++, and Go support for this pattern. | The KEK is a Cloud KMS key; IAM and KMS policy govern wrap and unwrap calls. | Cloud KMS Encrypt and Decrypt accept at most 64 KiB of input, so larger payloads must be encrypted locally. |
| AWS Encryption SDK | The SDK requests a plaintext data key and an encrypted copy, uses the plaintext key to encrypt the message, and deletes the plaintext key from memory after use. | The encrypted data key is protected by a configured AWS KMS key, which remains in the service. | The SDK manages the encrypted-key material in its message format, reducing the chance that application code handles wrapping details incorrectly. |
| Amazon EKS KMS v2 | The Kubernetes API server uses derived, single-use DEKs for individual resources and protects DEK material with a remote KEK. | AWS KMS holds the KEK; the cluster’s control plane requests the protected-key operations. | Designs must account for control-plane availability and the authorization needed to read encrypted API data. |
| Azure encryption at rest | Azure services use DEKs for data encryption and may cache them for service operation. | A KEK encrypts the DEK and is governed through Azure’s key-management controls. | Microsoft documents host and process protections for cached DEKs; administrators still need to apply least privilege and monitor key use. |
Operational choices that change an implementation
Where DEKs are generated and cached
Local generation avoids sending payloads to KMS. Decide whether to create a DEK per object, per batch, or per message class. Caching a plaintext DEK can reduce KMS calls but enlarges the window and scope of a memory compromise. If you cache, set a short lifetime, bound the number of objects, and clear the cache on privilege or tenant changes.
Rank #4
Who controls the KEK
A provider-managed key reduces administration, while a customer-managed KEK offers control over IAM, rotation schedules, disabling, deletion safeguards, and audit review. Separate KEKs by environment, tenant, or regulatory boundary when a single key would create unacceptable blast radius. Record the exact key resource and version in each envelope.
KMS call frequency, quotas, and limits
Every new DEK generally requires a wrap operation, and every read that lacks a usable cached DEK requires an unwrap. High object counts can therefore create KMS quota pressure even when payloads are small. Size limits apply to the bytes sent to KMS, not to the locally encrypted ciphertext. Use provider-supported batching or safe DEK caching only when its security implications are documented; never send a large payload to KMS merely to avoid designing an envelope format.
Audit and policy
Log KMS wrap and unwrap events with principal, key version, resource context, and outcome, but exclude plaintext keys and sensitive payloads. Alert on unusual principals, regions, rates, or failed authorization. Keep storage authorization separate from KMS authorization so an attacker must defeat both controls.
A durable envelope format
A minimal record can contain the following fields:
| Field | Purpose |
|---|---|
format_version |
Allows parsers to evolve without guessing how old records were produced. |
ciphertext |
The locally encrypted payload, including an authentication tag when the chosen format embeds it. |
wrapped_dek |
The DEK encrypted by the KEK; this is the only persisted form of the DEK. |
nonce or iv |
The unique AES-GCM nonce required for decryption. |
kek_id and, where applicable, kek_version |
Identifies the KMS key and version that must unwrap the DEK. |
algorithm |
Records the cipher and parameters rather than relying on an implicit default. |
authenticated_context |
Documents the associated data that must match before authentication succeeds. |
Do not treat this metadata as trusted just because it came from your database. Bind security-critical fields to authenticated data or validate them against the object’s expected identity. A copied envelope should fail when presented under the wrong tenant, object ID, or format context.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Rotation, rewrapping, and recovery
KEK rotation normally creates or selects a new KEK version; it does not require re-encrypting every byte of every payload. Existing wrapped DEKs remain associated with their original version until you rewrap them or migrate them on read. This distinction makes rotation practical for large archives.
Choose and document one migration policy:
- Batch rewrap: unwrap each DEK under the old version and immediately wrap it under the new version, without exposing or changing the payload ciphertext. Track progress and retain the old version until all required records are migrated.
- Read-time migration: when a record is successfully decrypted with an old version, rewrap its DEK under the current version and atomically update the envelope. This spreads KMS work over normal traffic but leaves cold data on older versions longer.
- Version pinning: keep a record tied to a specific version when retention or legal controls require it, and maintain that version for the entire retention period.
Before disabling or deleting a KEK version, inventory every wrapped DEK that references it and test restoration from backups. A backup containing ciphertext but no reachable KEK version is not recoverable. Conversely, retaining a KEK forever can preserve decryption capability beyond the intended data-retention period, so destruction must follow a deliberate, verified schedule.
Common failure modes and fixes
- Nonce reuse with AES-GCM: Reusing a nonce under the same DEK can undermine confidentiality and integrity. Generate a nonce for every encryption and enforce uniqueness in the encryption library or format.
- Plaintext DEKs in logs or dumps: Debug logging, tracing, crash reports, and memory snapshots can turn a sound design into a key leak. Redact key buffers and restrict diagnostic capture in production.
- Missing key identifiers: Without a KEK resource and version, a wrapped DEK may be impossible to unwrap after rotation. Store identifiers with every envelope and test restore procedures.
- Unauthenticated metadata: An attacker who can change the nonce, tenant ID, or algorithm field may cause confusion or cross-context attacks. Authenticate associated data and reject mismatches.
- Overbroad KMS permissions: Granting every application principal unrestricted decrypt access defeats separation of duties. Scope permissions by service, environment, key, operation, and encryption context.
- Assuming KMS availability is optional: A service outage or denied request prevents unwrapping. Define timeout, retry, alerting, and recovery behavior; never fall back to storing a plaintext DEK.
- Rotating without a migration plan: Changing a default key version does not automatically rewrite old envelopes. Track references and select batch, read-time, or pinned-version handling explicitly.
When envelope encryption is the right design
Use it when payloads exceed a KMS API’s input limit, when you need local high-throughput encryption with centralized key governance, or when many independent objects need separate data keys under a manageable set of customer-controlled KEKs. It is also a strong fit for multi-tenant systems that must separate object-level compromise from key-management authority.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesA direct KMS encryption call can be appropriate for a small secret that fits the service’s documented limit and does not justify a separate envelope format. Even then, use authenticated encryption where offered, record the key version, and apply least-privilege access. For larger or continuously streamed data, keep the payload path local and reserve KMS for wrapping, unwrapping, policy, and audit.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
