Accounting for a key you destroyed

We have argued twice that cryptographic erasure is the only deletion method compatible with an archive you have promised not to change. Both times we noted that it shifts the burden from deleting data to accounting for a key, and moved on. This is the piece about the part we moved on from, and it is the part an auditor will actually test.

Where the burden goes

With conventional deletion, the question is “is the data gone?” and it is surprisingly hard to answer for anything replicated, cached or backed up.

With crypto-shredding the ciphertext is deliberately still there, and the question becomes “can this key be recovered by anyone, ever?”. That is a better question in three respects: it concerns one small object rather than a diffuse set of copies, that object has a recorded lifecycle, and hardware exists specifically to constrain where it can go.

It is not, however, an easier question to answer carelessly.

Your erasure claim is exactly as strong as the weakest moment in that key’s life, and it only takes one forgotten copy to make the claim false.

The five moments that matter

Backup is where programmes fail. Every other stage tends to be deliberate, someone chose the HSM, someone wrote the access policy. Replication is usually inherited: the key store was configured for high availability years ago, replicates to a secondary region, and that secondary is covered by a snapshot schedule nobody has revisited. Destroying the primary key achieves nothing while a copy sits in a snapshot with a ninety-day retention.

Why non-extractable keys are worth the trouble

A key generated inside hardware that cannot export it has a decisive evidentiary property: the list of places it could exist is short and provable. It was created there, used there, and destroyed there. There is no plausible copy because the interface never permitted one.

A key generated in application memory and written to a secrets manager has a much longer list: process memory, whatever swapped, the deployment pipeline that injected it, the developer laptop where it was tested, the log line someone added while debugging and removed the following week. Each is individually unlikely. Collectively they are exactly what a competent challenger will probe, and “we are confident it was not copied” is a weak answer under pressure.

The value here is not that the cryptography is stronger. It is that the argument is shorter, and a short argument is what survives scrutiny years later when the people who built the system have left.

What destruction evidence should look like

1. The destruction event itself, an auditable log entry from the key management system, ideally in a log the operator cannot rewrite.
2. A subsequent failed use.Underrated and cheap: attempt to use the key after destruction and record the failure. It converts “we issued a delete” into “the key demonstrably no longer functions”.
3. The certificate binding it to the subject and archive, so the destruction is tied to the specific erasure request, the structure covered in the certificate piece.
4. Retention of all of the abovefor at least as long as the data’s own obligation. Deleting your evidence of deletion is a real and recurring mistake.

Four questions for your own programme

• Where is each subject key generated, and has it ever existed outside hardware?
• Enumerate every place it could have been copied, including DR, snapshots and pipelines. Verify, do not assume.
• What is written down when a key is destroyed, and who can alter that record?
• Do you test destruction by trying to use the key afterwards?

Most programmes we have seen can answer the first and third confidently, hesitate on the second, and have never considered the fourth. The second is the one that decides whether the erasure claim is true.