Restore-safe deletion lab

What if an old backup brings a deleted key back?

EraseKey is a small FastAPI project that tests one awkward edge case in cryptographic deletion: stale database state can restore both the ciphertext and the wrapped key needed to read it.

View the code Run it locally

EraseKey Restore Lab dashboard showing deletion surviving a stale restore

Problem

Deleting the row is not the hard part.

Backups, replicas, exports, and old snapshots can outlive the live database row. Envelope encryption helps by making old ciphertext unreadable, but there is a second failure mode: if the wrapped key and deletion record live in the same database, a restore can bring both the key and the forgotten deletion state back at once.

Mechanism

EraseKey keeps deletion continuity outside SQLite.

1. Encrypt per subject

Records are encrypted with subject-scoped data keys, wrapped by the configured key provider.

2. Destroy the wrapped key

Finalization removes the wrapped subject key. Ciphertext remains, but the API can no longer decrypt it.

3. Reapply the receipt

A signed receipt journal sits outside the app database and drives re-erasure after stale restores.

Try it

Run the Restore Lab locally.

git clone https://github.com/Qarait/EraseKey.git
cd EraseKey/mvp/erasekey
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r requirements.txt -r requirements-dev.txt
uvicorn app.main:app --reload

Open http://127.0.0.1:8000/dashboard and run the scenario.

Boundaries

This is a lab, not a compliance product.

No production tenant authentication.
Local receipt files are for demonstration, not legal evidence.
Real deployments need immutable receipt storage and managed signing keys.
The audit chain still needs an independently trusted head.

The useful part is the shape of the failure and the continuity protocol, not the claim that this repository is production-ready.