Envelope Encryption: Asymmetric for the Key, Symmetric for the Data

This article has three layers:

1. Layer 1: The Intuition: Putting the key in an envelope
2. Layer 2: Real-World Use: Cloud KMS, PGP, HPKE, client-side encryption
3. Layer 3: Principles and Engineering details: The full ECDH + HKDF + AEAD workflow, large file chunking, and common mistakes

Layer 1: The Intuition

1.1 Putting the key in an envelope

Imagine you want to send a box of valuables to a friend:

1. Buy a new padlock and lock the box (symmetric encryption of the data; it is fast and can lock large items);
2. Put the key to this padlock inside a special envelope that only your friend can open (encrypt the small key using your friend's public key);
3. Send the box and the envelope together.

When your friend opens the envelope to get the key, they can then open the box. No one in transit can get the key, so no one can open the box.

1.2 Why not encrypt the entire file directly with a public key?

Thus, each plays to its strengths: asymmetric encryption is only responsible for the few dozen bytes of the key, while symmetric encryption handles everything else.

Layer 2: Real-World Use

Key rotation becomes very cheap: When rotating the master key, you only need to re-seal each DEK (each only a few dozen bytes), rather than re-encrypting terabytes of data. This is a major reason why envelope encryption is widely adopted in cloud services.

Layer 3: Principles and Engineering

3.1 Full workflow based on ECDH

The receiver pre-generates a long-term key pair: private key $x$, public key $X = xG$.

Sender:

1. Generates a pair of ephemeral keys $y$, $Y = yG$;
2. Computes the shared secret $S = yX = xyG$ (ECDH, see "Diffie–Hellman and Discrete Logarithms", Elliptic Curves);
3. Uses HKDF to derive a symmetric key $K$ from $S$;
4. Uses AEAD (such as AES-GCM, ChaCha20-Poly1305) and a random nonce to encrypt the data, resulting in ciphertext and an authentication tag;
5. Sends $(Y,\ \text{nonce},\ \text{ciphertext})$.

Receiver: Uses their own private key to calculate $xY = xyG = S$, derives the same $K$, and then decrypts and verifies the tag.

An eavesdropper who only sees $X$ and $Y$ would have to solve the Elliptic Curve Discrete Logarithm Problem to calculate $xyG$.

3.2 Why HKDF is necessary

The shared secret $S$ obtained via ECDH is the coordinate of a point on a curve; it is not a uniformly random bitstring (for example, it must satisfy the curve equation) and cannot be used directly as an AES key. HKDF consists of two steps:

• Extract: Uses HMAC to "mix" the non-uniform input into a pseudo-random key;
• Expand: Combines the key with parameters like info (e.g., "file encryption for app v1") to derive a key of the required length.

The info parameter also enables domain separation: the same shared secret can derive unrelated keys for different purposes.

3.3 Why AEAD is necessary

Encryption without authentication is insufficient: although an attacker cannot read the ciphertext, they might modify it to make the decryption result change according to their intent (see malleability in "One-Time Pad"). AEAD (Authenticated Encryption with Associated Data) generates an authentication tag during encryption; if even a single bit of the ciphertext is altered, decryption will fail immediately.

3.4 Large files: Chunked encryption

It is impractical to read a multi-gigabyte audio file into memory all at once for encryption. The standard approach is:

1. Generate a random content key and seal it using the envelope method;
2. Use this content key to perform AEAD on the file in chunks, where each chunk includes a sequence number and the final chunk includes an "end" marker;
3. The sequence numbers and end markers prevent an attacker from reordering, deleting, or truncating data blocks.

The secretstream interface in libsodium is designed this way, allowing for encryption while recording.

3.5 Common mistakes

Therefore, the safest choice in practice is to use high-level abstractions (libsodium's sealed box, HPKE libraries, or Cloud KMS SDKs) rather than assembling low-level primitives yourself.

Summary