Encryption in transit, key rotation and crypto-shredding

How does destroying a key delete data?

Encryption in transit

Here the adversary is different. The network is a shared medium with an unbounded number of intermediaries (routers, proxies, switches) that you did not choose. TLS (Transport Layer Security, the protocol behind HTTPS) gives three things: confidentiality, integrity (changes are detected) and authentication of the server. mTLS (mutual TLS) also authenticates the client. At that point it stops being a protection mechanism and becomes an identity mechanism: the certificate is a proof-of-possession credential bound to the channel, which is the strongest credential form described in Identity and access.

There are two corrections.

TLS is no longer expensive. The folklore that it is comes from before CPUs had AES hardware instructions (AES-NI). Bulk symmetric encryption now runs at GB per second per core on any modern CPU. The cost that remains is the handshake: asymmetric (public-key) operations plus network round trips. That is why the mitigations are session resumption (reusing earlier negotiated state), connection pooling and keep-alives. These are networking mechanisms being used for a security reason, and knowing that saves you from inventing a new solution.

"Encrypted in transit" is usually true only at the perimeter. If TLS ends at a load balancer or proxy, every hop behind it is plaintext on a network you share with other tenants. Cross-availability-zone traffic, shuffle traffic (data redistributed between workers during a query) and replication traffic are the high-volume flows. They are also the ones most often left unprotected, because they are where the overhead was historically noticed. If your threat model includes anyone inside the datacenter network, perimeter TLS does not address it.

And TLS protects content, not metadata. Message size, timing, frequency and destination all survive. Pipeline traffic is unusually regular and periodic, so a passive observer learns a lot about what runs, when and how much data moved, without decrypting anything.

Compression and length

Length is the piece of shape that matters most, because compression turns it into a reading channel. Encryption must come after compression, since ciphertext does not compress. But a compressor makes repeated text shorter, so after compression the length of the ciphertext depends on whether two parts of the plaintext match. If an attacker can place text of their choosing into the same compressed stream as a secret (a header next to a session token, a search term echoed into a page that also holds an account number) and can watch the size of what is sent, they can guess the secret one piece at a time: a guess that matches compresses better, and the message gets measurably shorter. Repeat for each character and the secret is read without the key ever being touched. Attacks of this kind against encrypted web traffic are known as CRIME and BREACH.

Nothing about the cipher is wrong; the leak is in what was compressed together. So the escapes are about context, not cryptography:

• Never compress a secret in the same context as attacker-influenced input. Compress them separately, or not at all.
• Keep secrets out of compressed payloads, or randomize them per message so a guess has nothing stable to match.
• Hide the length: pad to fixed sizes or add random padding, which costs bandwidth and only blurs the signal.

For an internal pipeline with no attacker-controlled input next to secrets, this is rarely a live threat. Wherever a system echoes user input beside something secret and compresses the result, it is.

In one sentence: transit encryption is cheap in bulk and expensive in handshakes, protects content but not shape, and typically stops at the perimeter.

Key rotation and crypto-shredding

Rotation: derive it from its real purposes

The stated reason for rotation is usually wrong. Rotation exists for two reasons:

1. To bound the volume of ciphertext produced under one key. Cryptographic constructions need this for their security bounds to hold.
2. To bound the time window in which an undetected key compromise yields plaintext.

What rotation does not do is undo a compromise. An adversary who captured the ciphertext and the key that decrypts it keeps that plaintext forever. Rotation limits future exposure. Saying "rotate keys regularly to stay secure" without this qualification leads people to treat rotation as remediation, and it is not.

The mechanics matter too. Re-encrypting data costs O(data). Re-wrapping a data key costs O(number of keys). Envelope encryption makes the second cheap, so almost everyone "rotates" the wrapping key and leaves the data keys alone. Be honest about what that achieves: the bytes on disk are still encrypted under the original data key, forever, unless the data is rewritten. Rotating at the wrapping layer bounds the exposure of the key service's key material, not of the data keys. Real data-key rotation needs a rewrite of everything (the same table maintenance job that compacts files). It therefore happens rarely, and "we rotate annually" often means something much weaker than it sounds.

Crypto-shredding

Crypto-shredding is the one mechanism here with a property nothing else has.

Recall the immutable storage grows an indirection layer plus a collector law. When storage is append-only, deletion becomes a rewrite, and the rewrite must reach every copy: backups, replicas, snapshots, caches, the offsite tape, and the copy someone made for a dev environment. In practice you cannot list all copies, so you cannot prove deletion.

Crypto-shredding changes the problem. If the data is reachable only through a key, then destroying the key turns every copy into noise, including copies you do not know about. Deletion costs O(1) in data volume, and its reach is larger than your inventory. It is the only deletion mechanism that is sound in a distributed, backed-up, append-only world.

Example. Hollis stores each patient's lab_results rows encrypted under a key for that patient. When patient P-1042 requests erasure, Wei deletes one key from the key store. Every Parquet file, backup tape and notebook export that holds P-1042's ciphertext is now unreadable, without anyone finding those copies.

It has three sharp prices.

1. Key granularity must equal deletion granularity. Per-subject erasure needs a per-subject key. For 2.1 million patients that is 2.1 million keys, so the key store has its own scale, latency and durability needs. A file with rows from many subjects now contains many keys' worth of ciphertext. That kills block-level compression and forces row-level encryption, which is the same performance collapse as per-column encryption through a different door.
2. You have converted a confidentiality problem into a durability problem with inverted failure modes. Lose a key by accident and you have destroyed data irrecoverably. Leak a key and you have disclosed everything under it. These two risks pull key management in opposite directions: backups of the key store make accidental loss survivable and make shredding unprovable. You cannot have both for the same key. This is the costs are relocated, never removed law in a very pure form: the cost did not vanish, it became a different kind of risk.
3. It rests on a current engineering claim, computational infeasibility, not on a permanent one. Ciphertext captured today may be decryptable later. And whether key destruction legally counts as erasure is genuinely contested. Regulators and legal commentators differ. The general direction is that it is strong pseudonymization rather than unambiguous deletion, and the answer varies by jurisdiction. Do not build a compliance position that depends on the question being settled.

In one sentence: rotation bounds exposure in time; shredding turns deletion from a rewrite into a key destruction, and buys that with a key store whose loss is data loss.