How Do You Rotate Keys After Encrypting Files? Envelope Encryption Explained

The conclusion first

Large files are generally not encrypted directly with a master key stored in KMS. A mature design uses two keys with different responsibilities:

• A data encryption key (DEK) encrypts the file or data.
• A key encryption key (KEK) encrypts, or wraps, the DEK and remains in KMS or an HSM.

flowchart LR
  F[Plaintext file] -->|DEK · AES-GCM| C[Encrypted file]
  D[DEK] -->|KEK · KMS wrap| E[Encrypted DEK]
  K[KEK<br/>never leaves KMS] --> E

A real system does not have only two fixed keys. A small number of KEKs usually protects many DEKs:

One KEK
├── wraps the DEK for File A
├── wraps the DEK for File B
└── wraps the DEK for File C

Google Cloud recommends generating DEKs locally, storing them only in encrypted form and selecting their granularity according to the data, while keeping KEKs centralized in KMS. Google Cloud envelope encryption

Why use two layers?

Encrypting every file directly with one master key creates several problems:

• KMS encryption APIs are normally intended for small values, not large file transfer.
• Sending every file operation through KMS adds latency and cost.
• Replacing the master key may require decrypting and re-encrypting every file.
• One key has a very large blast radius when an incident occurs.

Envelope encryption gives high-throughput symmetric encryption to the DEK and asks KMS to protect only the small DEK. AWS similarly recommends encrypting data with a data key, storing the encrypted data key beside the ciphertext, and removing the plaintext data key from memory as soon as possible. AWS KMS data keys

The write and read paths

Encrypting a file

1. Generate a random DEK.
2. Encrypt the file with the DEK and authenticated encryption such as AES-256-GCM.
3. Ask KMS to wrap the DEK with a KEK.
4. Store the encrypted file, encrypted DEK and required metadata.
5. Remove the plaintext DEK from memory.

{
  "objectId": "document-123",
  "ciphertextUri": "oss://secure/document-123.enc",
  "encryptedDek": "base64...",
  "kekId": "document-encryption-key",
  "kekVersion": "v3",
  "algorithm": "AES-256-GCM",
  "nonce": "base64...",
  "authTag": "base64...",
  "encryptionSchema": 1
}

Decrypting a file

1. Read the encrypted DEK and KEK metadata.
2. Ask KMS to unwrap the encrypted DEK.
3. Use the temporary plaintext DEK to decrypt the file.
4. Verify the authentication tag.
5. Remove the plaintext DEK from memory.

The application does not need—and should never store—the KEK in an environment variable or configuration file. It holds only an identity with narrowly scoped permission to call KMS.

Rotation does not always mean re-encrypting every file

There are at least three distinct rotation situations.

Routine periodic rotation

KMS creates a new key-material version under the same logical key:

Old data → KEK v1 / v2 remains available for decryption
New data → uses the current KEK v3

This normally does not re-encrypt existing files or replace their DEKs. AWS KMS selects the correct old material during decryption while the logical Key ID remains unchanged. AWS KMS key rotation

Retiring an old KEK: rewrap the DEK

If the goal is to remove every dependency on an old KEK, there is no need to touch the large file first. Rewrap each encrypted DEK:

flowchart LR
  O[Encrypted DEK<br/>old KEK] --> U[Unwrap]
  U --> D[DEK<br/>memory only]
  D --> W[Wrap with new KEK]
  W --> N[Encrypted DEK<br/>new KEK]
  F[Encrypted file] -. unchanged .-> F

Some KMS products can perform this transformation without exposing the plaintext DEK to the application. This is the operational benefit of a two-layer design: rotate small key material rather than all large data.

A DEK or algorithm is compromised

If the DEK itself is exposed, rewrapping does not help. The attacker already has the key that decrypts the file. The system must:

1. Generate a new DEK.
2. Decrypt the existing ciphertext.
3. Re-encrypt the file under the new DEK.
4. Wrap the new DEK with a safe KEK.
5. Retire the old ciphertext and key material.

If a KEK may be compromised, assess whether the attacker could also obtain encrypted DEKs, ciphertexts or backups. That scope determines whether all affected DEKs and files must also be replaced. AWS explicitly notes that rotating a KMS key does not remediate a compromised data key.

A safe rotation procedure

Production systems should not create a new key and immediately delete the old one. A safer sequence is:

1. Create a new KEK version
2. Send all new writes to the new version
3. Rewrap old encrypted DEKs in the background
4. Count all data still dependent on the old version
5. Verify reads and backup restoration
6. Keep the old KEK enabled during observation
7. Disable the old KEK
8. Observe again and exercise rollback
9. Schedule destruction only after no dependencies remain

The rewrap job should support idempotency, checkpoints, retries, audit logs and safe metadata updates. When a file can change concurrently, use a version field or compare-and-swap so that migration cannot overwrite a newer encrypted DEK.

Backups are the dependency most often missed

Production may be fully migrated to v3 while an old snapshot still requires v1:

Production data → KEK v3
Six-month-old backup → KEK v1

As long as the backup must remain restorable, v1 cannot be destroyed. The choices are to migrate the backup, wait for its retention period to expire, or explicitly accept that destroying the key makes the old data permanently unrecoverable.

Google Cloud also warns that rotation does not automatically re-encrypt existing data and that destroying a key version still in use can cause permanent data loss. Google Cloud key rotation

Separate permissions as well as keys

Mature key management defines who may perform each operation:

• Applications may wrap and unwrap only with an approved KEK.
• Security administrators configure rotation policy but cannot read business data.
• Operations jobs can run migration but cannot export KEKs.
• Disabling and destroying keys requires separate approval and a waiting period.
• Generate, decrypt, rewrap, disable and destroy operations are audited.

If KMS supports an encryption context or AAD, tenant, object type or purpose can be cryptographically bound to the ciphertext. These fields may appear in audit logs, so they must not contain secrets. AWS KMS encryption context

Practical decision table

The final principle

Key rotation is not periodically replacing an environment variable. A complete design must identify which DEK encrypts each object, which KEK version protects that DEK, which production data and backups still depend on old versions, and when those versions can be retired safely.

Envelope encryption separates the lifecycle of the data from the lifecycle of the master key. Most rotations then move only encrypted DEKs. Re-encrypting large data is reserved for a real compromise or an algorithm migration, where that cost is genuinely necessary.