Crypto-shred erasure

DPDP §12 erasure should mean gone. A database DELETE or an in-place scrub leaves recoverable copies in dead tuples, the write-ahead log, and backups. NoIdMe avoids that with crypto-shredding.

How it works

• Seal at write — free-text PII (grievance bodies, correction values, nominee name/contact) is encrypted under a per-principal data-encryption key (DEK) before it ever hits a row. The row stores ciphertext-by-reference, never plaintext.
• Shred on erase — §12 erasure destroys that principal's DEK. The ciphertext that remains in tables, WAL and backups is now undecryptable — unrecoverable, by cryptography rather than by policy.
• Sticky tombstone — once shredded, the key cannot be re-minted; a later write for that principal fails closed rather than silently resurrecting data.

Reversible grace window

Erasure runs through a reversible grace window first (also used as the Rule-8 48-hour pre-erasure intimation period). Only after the window elapses is the DEK shredded and a one-way §12 marker appended to the chain — so the marker never attests an erasure that didn't happen.

Why it matters

"We deleted it" is hard to prove and easy to get wrong. "We destroyed the only key that could read it" is a cryptographic fact you can stand behind in an audit.