VERIFIABLE DELETION

Prove you forgot —
not just promise it.

GDPR Article 17 gives every person a right to erasure. Everyone claims deletion; almost nobody can prove it. Proof-of-Forgetting makes an erasure verifiable — pairing a signed destruction record with a cryptographic proof that the subject is absent from your current data.

→ Anchored Retention ReceiptsLive in Dekimu Hub

WHY A PROMISE ISN'T PROOF

When a customer asks you to erase their data, you delete some rows and reply “done.” But a deletion claim with no evidence is just a promise — unfalsifiable, and worthless to an auditor or a court. Article 17 obliges erasure; it does not, on its own, give you a way to demonstrate that it happened. Proof-of-Forgetting closes that gap with cryptography instead of trust.

TWO PAIRED CLAIMS

Neither half is honest on its own. A receipt only proves you said you deleted; an absence proof carries no record of when, or by whose authority. The pair is what makes “we can prove we forgot you” literally true.

+

Destruction receipt

Positive evidence

A signed, append-only record that the subject's encryption key was destroyed at a specific time, under a named key authority. Proof that an erasure event happened.

Non-inclusion proof

Negative evidence

A proof against a signed, published roster root that the subject is absent from current state — checkable by an auditor without taking your word for it.

ENFORCED BY CRYPTOGRAPHY, NOT BY TRUST

Erasure is guaranteed by key destruction, not by a delete query someone has to be trusted to have run. It uses only standard AES-256-GCM and a sorted Merkle tree — no novel cryptography.

01

Per-subject key

Each subject's personal data is encrypted under its own random 256-bit key (AES-256-GCM). The bulky ciphertext may live anywhere — backups, replicas, logs.

02

Tiny wrapped key

Only the small data-encryption key sits in a hardened, retention-tight registry, itself wrapped by a workspace master key that is never destroyed and never appears in a receipt.

03

Crypto-shred

Erasure deletes that one registry row. The random key is gone; the ciphertext — wherever copies live — becomes permanently unreconstructable. Nothing is left to leak.

04

Signed roster

Active subjects form a signed, sorted Merkle roster. One inclusion proof over interval leaves shows whether a subject is, or is no longer, in current state — with leaf count and previous root signed in so a roster can't be silently truncated or rolled back.

WHAT IT PROVES — AND WHAT IT DOESN'T

The pair is precise about its own limits. It proves erasure happened and that the subject is gone from current state; it does not pretend to chase down every copy that ever existed.

Proves

  • An erasure event occurred at a specific time, under a named key authority (signed destruction receipt).
  • The subject is absent from the current signed roster (non-inclusion proof against the published root).
  • The roster was not silently truncated or rolled back (signed leaf count + previous-root chain).

Does not prove

  • ×That every ciphertext copy was physically located and deleted — crypto-shred makes copies unreconstructable, it does not hunt them down.
  • ×That data your workspace never held, or that left through a third party, was erased — the proof covers what your Hub workspace manages.
  • ×More than your retention discipline allows: it is only as strong as the wrapped key being the single copy, held under a short or no backup window.

REFERENCES

Proof-of-Forgetting is a compliance-management capability, not a law firm. It does not provide legal advice and does not certify compliance. It proves erasure for the data your Hub workspace manages; you remain responsible for processing that happens elsewhere. Legal review is recommended.