Swag
← Thinking

Crypto Shredding

4 min read#privacy#architecture#cryptography

An event log is a diary written in ink. Every entry stays exactly as it was written, and that permanence is why we trust it: we can replay the past, audit a decision, and rebuild any state from first principles.

Then someone asks to be forgotten, and the permanence becomes a burden. Their name sits in an event from three years ago, and that event has since travelled to replicas, warehouses, backups, and other teams’ topics. Chasing every copy is a hunt through terabytes, and rewriting history would spend the trust the log earned.

Erase the key, keep the log

Crypto shredding turns the question around. Rather than deleting personal data everywhere it lives, we make it unreadable everywhere at once.

Each person receives an encryption key of their own. Before an event enters the log, its producer seals the personal fields with that key. The rest of the event stays readable, so the system keeps routing and counting. A consumer that needs the personal data asks a key service to unlock it. When someone asks to be forgotten, the key service destroys their key, and the sealed fields in every copy and every backup turn into noise.

Five parts and one boundary: the keys live apart from the log.

Crypto shredding architecture Producers seal personal data with a per-person key from the key service and write it to the event log. Consumers ask the key service to unlock it. A master key protects the keys. Destroying a person's key erases them everywhere. keys live elsewhere seal unlock wraps Producers seal personal data Event log sealed, kept forever Consumers unlock, or show erased Key service one key per person Master key protects every key Destroy a key and that person is erased everywhere.

Erasure happens in one place, which keeps the key service small enough to audit and simple enough to trust.

Where the design asks for care

  • Key backups. A snapshot that still holds a key keeps that person alive until it expires, so key backups deserve a short, published retention window.
  • Plaintext copies. A search index or analytics export that stored an email address in the clear keeps it, so every derived store should hold ciphertext or offer its own deletion path.
  • Readable fields. Anything left in the clear must be free of personal detail. An email address used as an identifier, or a name in a free-text note, identifies the person as plainly as the sealed data would.

Whether a destroyed key counts as erasure is a question for your lawyers, because regulators differ on the details.

Plan for forgetting early

The strongest erasure is the one that was easy from the start. Keep personal data out of events whenever a reference to an ordinary table will do. Seal only what has to travel with the event. Then test the whole path by erasing a test person and searching every store afterward. Forgetting becomes a single decision, made once, in one small place.