Cloud Envelope Encryption & Key Rotation (2D)

Cloud KMS Setup

Data objects 10

View spin speed 0.15

Key State

KEK v1 · 10 unique DEKs · 0 objects exposed

KEK version

Unique DEKs

Blast radius

0 / 10

Rotations

How it works

Cloud KMS services (AWS KMS, GCP Cloud KMS, Azure Key Vault) never encrypt bulk data with the master key directly. Instead they use envelope encryption:

DEK_i        = random 256-bit key, one per object
Ciphertext_i = Encrypt(DEK_i, plaintext_i)
WrappedDEK_i = Encrypt(KEK_v, DEK_i)   ← stored alongside the object

Decrypt: DEK_i = Decrypt(KEK_v, WrappedDEK_i)
         plaintext_i = Decrypt(DEK_i, Ciphertext_i)

Rotate master key — the KMS mints a new KEK version. Every WrappedDEK is simply re-wrapped under the new version; the bulk ciphertext is never touched, so rotation is cheap even for petabytes of data.
Envelope encryption ON — every object gets its own DEK. If one DEK leaks (a compromised process, a debug log, a misconfigured cache), only the single object it protects is exposed — the graph shows one red node.
Envelope encryption OFF — every object is "encrypted" with the same shared key. The same single leak now exposes every object at once: this is the blast-radius argument for per-object DEKs, and why "one key encrypts everything" is a real anti-pattern.
Simulate DEK leak — picks one random DEK and marks it exposed, then traces every object wrapped under it. Blast radius = exposed objects ÷ total objects.

The KEK itself is never exported from the KMS's hardware boundary — only Encrypt and Decrypt calls cross it, which is why compromising an application's memory can leak a DEK but essentially never the KEK.

Reading the graph: drag inside the ring view to spin it manually; scroll/pinch to zoom. The strip below the ring is a rolling history of blast-radius events — each bar is one leak simulation, height = fraction of objects exposed.

Master key (KEK) Data-encryption key (DEK) Protected data object Exposed data object

drag = spin · wheel = zoom