Eventsourcing Patterns: Crypto-Shredding

Encrypt sensitive information in an event and delete the key.

By @mathiasverraes
Published on 13 May 2019


Encrypt sensitive information in an event and delete the key.


The problem is the same as for Forgettable Payloads: some attributes of an event should not be read by all consumers, and we should be able to delete them, without touching the event store.


Encrypt the sensitive attributes, with a different encryption key for each resource (such as a customer). Only give the key to consumers that require it. When the sensitive information needs to be erased, delete the encryption key instead, to ensure the information can never be accessed again. This effectively makes all copies and backups of the sensitive data unusable.


The Crypto-Shredding pattern is of course only as good as your encryption and your key management practices. Today’s unbreakable encryption could be tomorrow’s infosec disaster.

If the consumers (such as projections) consistently store all sensitive information using encryption, it makes deletions extremely cheap, as only the key must be deleted, as opposed to deleting all copies. But this benefit can be achieved using Forgettable Payloads. Both patterns do not solve the problem of consumer storing encrypted data, or using the encrypted data to compute some new value (that may still be sensitive).

There is also a concern of legality: is Crypto-Shredding a sufficient implementation of delete requests under GDPR, or does the law consider the data not truly deleted? EDIT: Read Harrison J. Brown’s comment on Crypto-Shredding and GDPR