Encryption at Rest, Field-Level & E2E

Encryption at rest makes stolen storage useless

Encryption at rest exists to make stolen storage useless: a lost disk, a leaked backup, or an exfiltrated database snapshot should decrypt to nothing. The critical design lever is granularity, because it decides how much a single breach exposes and what you can still do with the data.

Envelope encryption is the engine

You do not encrypt terabytes directly with a master key. Instead a Data Encryption Key (DEK) encrypts the actual data, and a Key Encryption Key (KEK) living in a KMS or HSM wraps (encrypts) the DEK. You store the wrapped DEK next to the ciphertext; to read, you send the wrapped DEK to KMS, which unwraps it (the KEK never leaves the HSM), and you decrypt locally. This gives cheap key rotation (re-wrap DEKs, no data rewrite), a hardware-guarded root of trust, and per-tenant or per-record DEKs so one leaked DEK exposes one tenant, not everyone.

 plaintext --AES-256-GCM(DEK)--> ciphertext   [stored together]
     DEK --wrap(KEK in KMS/HSM)--> wrapped DEK  [stored together]
     KEK  never leaves the HSM boundary
 breach of storage alone  => attacker has ciphertext + wrapped DEK, no KEK => useless

The granularity ladder

• Full-disk / volume encryption (LUKS, cloud EBS encryption). Protects a physically stolen disk. But a running app and anyone with DB access see full plaintext, so it does nothing against a compromised app or a leaked query result. Zero searchability cost.
• Database TDE (Transparent Data Encryption). The DB encrypts files/pages. Same weakness: it is transparent, so a valid connection reads plaintext. Protects backups and stolen data files. Full query/index functionality preserved.
• Application / field-level encryption. Your app encrypts specific columns (SSN, card number) before writing, so the DB only ever holds ciphertext. A stolen snapshot and a compromised DB both reveal nothing for those fields. The cost is searchability: you cannot do WHERE ssn = ? or range queries on a randomized-encrypted column.
• Client-side / end-to-end (E2EE). The client encrypts so the server never sees plaintext at all (Signal, WhatsApp, 1Password). Maximum protection, maximum functional cost: the server cannot search, index, or process the data, and you must solve key distribution and recovery.

The searchability tradeoff has a nuance: deterministic encryption (same plaintext to same ciphertext) allows equality lookups and joins but leaks which rows share a value and enables frequency analysis; randomized encryption (fresh nonce each time, the AES-256-GCM default) leaks nothing but kills search. Real systems use randomized for most fields and reach for deterministic, blind indexes, or dedicated searchable-encryption schemes only where lookup is required, accepting the leakage.

Interview nuance: "crypto-shredding" is how encryption meets GDPR erasure and retention. If each user's data is encrypted under a per-user DEK, deleting that one key makes all their data unrecoverable instantly, even copies sitting in backups, replicas, and archives you cannot practically hard-delete. So a per-tenant/per-user key hierarchy is not just breach isolation, it is your "right to be forgotten" mechanism. And remember to encrypt backups and logs too; a plaintext backup or a log line full of PII is the most commonly forgotten copy.

Recap: use envelope encryption with per-tenant/per-user DEKs wrapped by an HSM-held KEK, pick granularity (disk, TDE, field, E2E) by how much breach exposure and searchability you can trade, and design keys so crypto-shredding gives you instant, backup-proof erasure.