Envelope encryption

What it is

Envelope encryption splits encryption into layers. The inner layer encrypts the actual data with a per-record key, called a data encryption key or DEK. The outer layer encrypts that DEK with a master key, sometimes called a key encryption key or KEK. Only the outer key, which is small, ever needs to be unlocked directly, and it never decrypts data on its own.

The point of the name is the metaphor: the data sits inside an inner envelope, and the inner envelope sits inside a stronger outer one. The pattern shows up in any storage system that needs to encrypt many records under a small number of keys without ever exposing the master key to the application that reads the data.

How it works

Three pieces of key material, used in order:

1. Generate a fresh data encryption key (DEK) for each value you want to store. Typically a 256-bit random key.
2. Encrypt the value with the DEK using a symmetric authenticated cipher like AES-256-GCM.
3. Wrap the DEK with a master key (the KEK). Store the wrapped DEK alongside the ciphertext, never the raw DEK.

To read the value, the reverse: fetch the wrapped DEK, unwrap it with the master key, decrypt the ciphertext with the DEK, then zero the DEK from memory. The master key spends most of its life idle and never sees plaintext data, only the small wrapped DEKs.

Why the layering matters

Three properties fall out of envelope structure that single-key encryption doesn't give you:

• Blast radius is small. A leaked DEK exposes exactly one record. A leaked master key alone exposes nothing; an attacker still needs the wrapped DEKs to make use of it.
• Rotation is cheap. Rotating the master means re-wrapping the (small) DEKs, not re-encrypting the (large) data values. A system with a million records can rotate its master key in seconds instead of hours.
• The master can live further from the data. Because it's only used to wrap small keys, the master can sit in a hardware security module, in a memory-only secret on a separate process, or behind a key-management service, with much tighter access controls than the bulk data needs.

The same structure also nests further. The master key itself can be wrapped by another key held even further from the system that handles ciphertext, creating a chain of envelopes where each layer's job is to wrap the one below it. The bulk data stays encrypted under fast symmetric keys; the keys that matter most spend their time wrapped and idle.

How SikkerKey uses it

SikkerKey applies envelope encryption in three layers, each storing only what it needs to:

1. Per-secret data key. Every secret value in your vault is encrypted with AES-256-GCM under a key generated just for that secret. The secret ID is bound into the encryption as additional authenticated data, so a ciphertext can't be silently swapped between records.
2. Per-project master key. Each project has its own master key that wraps the data keys belonging to that project. The master key is generated at project creation and stored in the database in wrapped form, never in plaintext.
3. In-memory unseal key. The key that wraps every project's master key lives only in memory after the server is unsealed. It's never written to disk, never logged, and never returned over the API.

The end state: if somebody walked off with the SikkerKey database tomorrow, every secret value, every data key, and every project master key would be opaque ciphertext, and no key on disk would decrypt any of them.