Erase one person from the storage you already have.
No migration. No copy. No proxy on your data path. If your objects are already encrypted under per-object data keys, AT-1 rewraps those keys under a per-subject key — and destroying that one key makes exactly that person unreadable, wherever the objects sit.
The number that matters
Measured through the command line on a 60-object, 3.9 MB store: all 60 object bodies byte-identical afterwards, and 4,800 bytes rewritten — 0.122% of the dataset. The object bodies are never read and never written. What changes is the small key sidecar beside them.
Why this exists
Cryptographic erasure normally has a hard precondition: the data had to be encrypted under a per-subject key when it was written. That makes it a fix for a future problem, while the pain that makes anyone pick up the phone is the data already sitting in their bucket.
We wrote that limit down ourselves, and then tested it rather than trusting it. Half of it survived and half did not. For plaintext it is exactly right — there is no key to destroy, and no vendor can invent one. But for data already encrypted client-side under per-object data keys, there is a retroactive path, and it turns out to be cheap.
What actually happens
Most systems that say “we encrypt at rest” — the S3 Encryption Client, the AWS Encryption SDK, Tink, and most in-house pipelines — produce the same shape: each object gets its own random data key, and that key is stored beside it, wrapped under one master key.
AT-1 unwraps each data key under your master and rewraps it under a fresh per-subject key. The ciphertext is untouched — it is not even read. Afterwards, destroying one subject's key makes their objects undecryptable and leaves everyone else exactly as they were. The cost is one key, not one per subject, so the quota and price ceiling that sinks the per-object-CMK approach never applies.
| Approach | Moves your data | Reaches old backups | The catch |
|---|---|---|---|
| Re-encrypt everything in place | read and rewrite every object; every backup taken before the pass still holds the plaintext, forever | ||
| One KMS key per object | AWS caps at 100,000 keys per region and bills ~$1 each per month — $100k/month at 100k subjects | ||
| Proxy in front of your bucket | puts a vendor on your primary data path, and they see every byte on read and write | ||
| AT-1 rewrap-in-place | rewrap the key sidecar only; one key total; reaches pre-existing backups if you destroy the master |
One question decides whether this is for you
Is your data encrypted with a key your application holds, or with SSE-KMS?
A key you hold — this applies, and it is days of work, not quarters. SSE-KMS — it does not: the wrapped data key is internal to S3 and never exposed, so there is nothing to rewrap. Plaintext — it does not, and nobody else can help you either without rewriting the data.
What we refuse to do
Three configurations produce a retrofit that completes, certificates that verify, and a subject who is still perfectly readable. That failure mode is worse than doing nothing, because it manufactures evidence of an erasure that did not happen. So:
- A data key shared between people.Rewrapping cannot split it — destroy one person's key and the identical data key is still reachable through someone else's wrapper. One data key is one erasure unit, permanently. We refuse and tell you which objects.
- Re-keying someone already erased. A late-arriving batch would otherwise mint a fresh key for a person you have certified as gone. We refuse.
- Data keys derived from the master. If your keys are computed as KDF(master, object_id) rather than randomly generated, the master regenerates any of them without touching a wrapper, so rewrapping erases nothing until the master itself is destroyed. A derived key and a random one are both 32 opaque bytes — nothing we can observe tells them apart, so we ask you rather than pretend to check.
What the certificate does and does not say
This is deliberately notan AT-1 erasure certificate, and it does not share a type, a schema or a page with one. An AT-1 archive is a single artefact whose hash is a complete commitment — there is nowhere else a person's rows can be. Over your storage there is no such artefact, only the objects you enumerated. So the scope is recorded as scope_declared_by: customer, on the face of the certificate, and there is no archive-hash field implying a completeness we did not establish.
The certificate also records master_destroyed, signed. It does not affect live reads — after the rewrap the old master opens nothing — but it decides entirely whether a backup taken before the retrofit is still readable. Claiming it falsely breaks the signature.
And because a retrofit can silently skip someone, there is a separate artefact for that: at1 erase attest-migration checks the migration against your own subject inventory and names anyone it missed. An erasure certificate cannot carry that and should never be asked to — it would verify perfectly for every subject the retrofit did cover.
Frequently asked
- Can you cryptographically erase one person from data that is already in my bucket?
- Only if that data was encrypted with a key. If it is sitting in plaintext there is nothing to destroy, and no product — ours or anyone else's — can make it cryptographically unrecoverable without rewriting it. But if your application already does client-side envelope encryption, where each object has its own data key wrapped under a master key you hold, then yes: AT-1 rewraps each data key under a fresh per-subject key, and destroying that one key renders exactly that person's objects unreadable. Not one byte of the objects themselves is moved.
- How much of my data gets rewritten?
- The key sidecar only, which is a few dozen bytes per object. Measured on a 60-object, 3.9 MB store: all 60 object bodies were byte-identical afterwards and 4,800 bytes were rewritten — 0.122% of the dataset. The object bodies are never read or written at all, which is why this takes minutes rather than the days a full re-encryption pass would take.
- Does this reach backups taken before I ever installed anything?
- Yes, and that is the surprising part — but the reach is total, not per-person. A backup taken before the rewrap holds ciphertext plus data keys wrapped under your old master key. Destroy that master after the rewrap is complete and those backups become unrecoverable. For everyone in them, not for one subject. That is a disaster-recovery decision with a date on it, not a compliance default, and our tooling records which way you chose in the certificate.
- Does this work with SSE-KMS or SSE-S3?
- No. With server-side encryption the wrapped data key is internal to S3 and never exposed, so there is nothing for us to rewrap. One question decides which conversation you are in: is your data encrypted with a key your application holds, or with SSE-KMS? If it is SSE-KMS, the honest options are a per-object CMK approach — which is capped by AWS quota and price — or a re-encryption pass.
- What could make this look like it works when it does not?
- Three configurations, and we refuse or flag all three rather than letting them through quietly. If one data key is shared across objects belonging to different people, rewrapping cannot split it: destroying one person's key leaves the identical data key reachable through someone else's wrapper. If you re-key a subject you have already certified as erased, you resurrect a destroyed key. And if your data keys were derived from the master rather than randomly generated, the master regenerates them without any wrapper at all, so rewrapping erases nothing until the master itself is destroyed. We can detect the first two and refuse. The third is undetectable from outside — a derived key and a random one are both 32 opaque bytes — so the tool asks you the question instead of pretending to answer it.
- How is this different from your erasable archive?
- The guarantee is weaker in one specific way, and we give it a different name and a different certificate type so the two can never be confused. An AT-1 archive is a single artefact whose hash is a complete commitment: there is nowhere else a person's rows can be. Over your own storage there is no such artefact, only the objects you enumerated for us. The scope of the erasure is your assertion, which we record and re-verify mechanically; it is not a boundary we established. The certificate says so on its face.
Honest scope. Figures on this page were measured on a synthetic 60-object store through the shipped command line, not modelled. Rewrap-in-place applies only to data already encrypted client-side under per-object data keys; it cannot touch plaintext, and it does not work over SSE-KMS. Destroying the master key to reach pre-existing backups makes those backups unrestorable for every subject in them, and is a decision for you to take and date, not a default we apply.