Skip to content

CONCEPT Cited by 1 source

Cryptographic Shredding

Cryptographic shredding is the technique of rendering data inaccessible by destroying (or denying access to) the encryption keys that decrypt it, rather than physically deleting the underlying bytes. The bytes can remain on disk, in backups, in replicas, in caches — but without the keys they are indistinguishable from noise.

It is the revocation primitive that makes concepts/envelope-encryption + concepts/cmk-customer-managed-keys a meaningful data-sovereignty story.

Mechanics

In an envelope-encryption hierarchy:

  • The root key (e.g. a customer's CMK in their KMS) wraps KEKs.
  • KEKs wrap per-segment DEKs.
  • DEKs encrypt the data.

Cryptographic shredding breaks this chain at the top:

  1. Customer revokes or deletes the root key (or removes the vendor's IAM role that allows unwrap).
  2. KEK unwrap calls fail.
  3. The vendor cannot recover any DEK it doesn't already have cached.
  4. Existing DEK caches expire (they're short-lived by design).
  5. All ciphertext becomes unreadable, immediately and irreversibly.

Databricks' Lakebase launch describes this wiring explicitly: on CMK revocation "unwrapping will then fail, rendering the data cryptographically inaccessible. As part of this process, all ephemeral compute instances are terminated to remove access to cached data." (Source: sources/2026-04-20-databricks-take-control-customer-managed-keys-for-lakebase-postgres)

Note the second clause: cryptographic shredding of storage is achieved by key revocation alone, but cached plaintext DEKs in running compute nodes must be actively destroyed too — usually by terminating the VM. In Lakebase this is the Lakebase Manager's job and ties into the patterns/per-boot-ephemeral-key pattern: each Postgres compute VM holds an ephemeral per-boot key that dies with the instance.

Why it matters

  • Physical deletion is slow and unauditable at scale. "Delete" in a distributed system might mean tombstone-in-metadata, and the actual erasure is a background compaction that may take hours, days, or never (for cold backups). Cryptographic shredding is synchronous: the moment the key is revoked, the data is inaccessible.
  • Shredding propagates across replicas, caches, and backups automatically. They're all encrypted with DEKs that chain to the shredded root. No need to enumerate and scrub every copy.
  • GDPR / right-to-be-forgotten has a crypto story. A per-tenant or per-subject CMK lets the data owner satisfy erasure obligations by destroying keys, independent of the backend's physical-delete SLA.
  • Compromise containment. If a vendor is breached, the attacker has ciphertext. Revoking the CMK cryptographically shreds it before the attacker can find (or still has cached) an unwrapped DEK.
  • Regulatory "fail-stop." Compliance audits can demand revocation drills; shredding is observable (unwrap-failures in the KMS audit log) and irreversible.

Caveats and failure modes

  • In-memory plaintext is the weak link. Any DEK or data that was decrypted and held in a process that the Lakebase-Manager-equivalent does not kill in time is at risk. This is why the compute-side story is always "terminate the VM, not just revoke the key."
  • Cached KEKs at the vendor side extend the shred horizon. If the vendor caches unwrapped KEKs for T seconds to reduce KMS load, that's a T-second window during which a revocation has not yet fully shredded. Short caches + key-change invalidation close this gap but never to zero.
  • Depends entirely on KMS integrity. If the KMS leaks root keys, or if the vendor's copy of the KEK survives revocation, shredding fails silently. This is why hardware-backed KMSes and third-party auditability matter.
  • "Inaccessible" ≠ "deleted" for some regulators. Some regimes still require physical erasure within a bounded window. Shredding is the online half; bulk erasure runs in background.
  • Recovery is symmetric — you cannot undo a shred. Operationally this means revocation is a one-way door; building "revoke in staging" drills and approval flows around it is a standard operational hygiene layer.

Seen in

Last updated · 200 distilled / 1,178 read