Right-to-erasure for compressed archives

AT-1 makes a compressed archive selectively erasable: each data subject's records are encrypted under their own key, so a GDPR/CCPA erasure request is satisfied by destroying one key — leaving the archive bytes unchanged and every other subject intact, with a signed certificate as proof. See the product overview for the why.

1. Build an erasable archive

Group rows by data subject and encrypt each group under a unique AES-256-GCM key.

# records.json: a JSON array of rows, each with a subject field (e.g. user_id)
at1 erase build records.json --subject-field user_id --out vault/
# -> vault/archive.json  (per-subject AES-256-GCM encrypted blocks)
#    vault/vault.json    (the key store — back this with a KMS/HSM in production)

2. Create a signing identity

Erasure certificates are Ed25519-signed so an auditor can verify them with your public key.

at1 erase keygen --out issuer.key      # Ed25519 keypair -> issuer.key + issuer.key.pub
# the issuer key signs erasure certificates; the .pub verifies them

3. Read and erase

Erasure destroys the subject's key and writes a certificate. The encrypted block stays physically in the archive but is unrecoverable; the operation is O(1) in archive size.

at1 erase read   vault/ 1337                       # the subject's records, across tables
at1 erase erase  vault/ 1337 --signing-key issuer.key --out-cert cert.json
at1 erase read   vault/ 1337                       # -> exits non-zero: ERASED
at1 erase read   vault/ 1338                       # -> still intact

4. Verify the certificate

at1 erase verify cert.json issuer.key.pub
# certificate signature: VALID  (subject 1337, erased 2026-06-19T19:19:06Z, archive-unchanged=True)

The certificate is a self-contained JSON artifact:

{
  "subject_id": "1337",
  "erased_at": "2026-06-19T19:19:06Z",
  "record_groups_erased": 1,
  "archive_hash_before": "d5b75e94…",
  "archive_hash_after":  "d5b75e94…",   // identical -> archive was not modified
  "key_destruction_proof": "242b2484…", // commitment to the destroyed key
  "issuer": "AT-1 DPO service",
  "signature": "dd141c4a…"              // Ed25519 over the above
}

How it works

  • Per-subject record-groups. All rows for one subject (across tables) are encrypted under one key, with the subject id bound as authenticated associated data (AAD).
  • Erasure = key destruction. The key is zeroed and removed from the vault; a tombstone records that it was destroyed (so the system can prove the key is gone, not merely missing).
  • Archive immutability. The certificate carries the archive content hash before and after — they are equal, proving the erasure modified no other data.
  • Verifiability. The certificate is Ed25519-signed; any party with the issuer public key can verify it, and any tampering invalidates the signature.

Production notes

  • Back the key vault with a KMS/HSM — the file vault (vault.json) is for evaluation. Erasure then means a KMS key-version destroy.
  • Propagate erasure to replicas/derived archives by replicating only the tombstone.
  • Anchor certificates to your existing tamper-evident integrity ledger for independent timestamping.

Honest scope

This uses cryptographic erasure (crypto-shredding), a method EU regulators recognise (EDPB Guidelines 5/2019, ICO, CNIL). We make no novel-patent claim — the value is the turnkey integration with a compressed, queryable AT-1 archive, per-subject grouping across tables, and the productised DPO workflow.