Memory wiping and proofs of secure erasure

How it works

Proofs of secure erasure (PoSE), introduced by Perito and Tsudik for low-cost embedded devices, rely on the bounded memory of such devices ². A verifier confirms that a device has erased its memory by having it fill that memory with data the verifier can check ³. Perito and Tsudik found this "particularly well-suited" to secure code update and to secure memory or storage erasure ².

A protocol has three phases ³:

1. Fill. The prover fills its memory. In the simplest version the verifier sends random data; in graph-based versions it sends a short seed, and the device computes a large set of hash-chained labels from it ³.
2. Challenge. The verifier asks for randomly chosen blocks, several times, and times each answer ³.
3. Decide. The verifier accepts only if every answer is correct and arrived within the time bound ³.

The graph construction makes it slow to recompute any missing label, so a device that tried to keep other data must fail the deadline ^{3 5}.

In AI verification, the AI 2040 plan proposes "periodic memory wiping on the inference units (which we think can be done through forced memorization)" ¹. The MIRI overview describes the same step: incompressible data is loaded until the device is full, and then random samples are challenged ⁴. Amodo generates the fill on the device from a verifier seed, following Bursuc et al. ⁵.

What it establishes

Amodo describes the goal as a verifier ensuring "the prover has fully overwritten its memory, with no information persisted across the wipe" ⁵. Amodo says wipes help to verify the "completeness" of declared workloads ⁵. In the AI 2040 plan they help ensure that the only persisting results are verified inference outputs ¹; see This compute runs inference, not training.

Wipes limit what can carry over between verification cycles, not what runs between them. The AI 2040 plan therefore pairs them with network taps and partial recomputation (Network taps and certifiers, Sampled inference recomputation) ¹. Amodo notes that all stores must be wiped at the same time, because otherwise "an attacker could simply move the data between the disks" ⁵.

Threat model

• Bounded memory. Perito and Tsudik assume bounded memory and a small read-only memory ².
• Distant helpers. Earlier software protocols assumed the device was isolated during the protocol ³. Bursuc et al. relax this: helpers may exist but must be far enough away that their round-trip times exceed the deadline ³.
• Round-trip time. Amodo assumes a 1 ms round-trip time, "expected to be a safe overestimate" ⁵.
• No remote memory. The MIRI overview says verification depends on ruling out remote memory access, "either via response latency or physical disconnection" ⁴.

Timed challenges are covered in Timed challenge-response and memory-occupation challenges.

Evidence

• Protocols. The core protocols are formally analysed ^{2 3}. Bursuc et al. ran their prototype on a standard desktop computer and simulated the erasure of 32 KB, which took 0.25 seconds ³.
• First Amodo test. Amodo ran the algorithm on a Raspberry Pi 5, erasing its RAM and a connected SSD ⁵.
• Amodo's July 2026 analysis. Scaling measured GPU and CPU throughputs, with an assumed 1 ms round-trip time, gave 2,565 seconds (43 minutes) for the RAM and HBM of a GB200 tray ⁵. Drive writes slowed sharply after about 12 GiB, so Amodo estimated over 24 hours for a GB200 system with 15 TB of storage ⁵. Challenge-phase calculations were still to come ⁵.
• Amodo's September 2026 update. Amodo attributed the slowdown to consumer drives' fast write cache running out ⁶. Six GPUs wiping one fast drive reached 6 minutes 41 seconds per TB ⁶. Amodo now expects "~2.5 hours to wipe an NVL72 system's storage", using a B200 label rate estimated from its GPU benchmarks, and reports that erasure speed, not drive speed, is the bottleneck ⁶.
• Public code. Amodo has published code for the disk-wiping path, which fills every sector of an NVMe drive with graph labels generated on NVIDIA GPUs ⁷. The repository excludes the verifier and the RAM and GPU-HBM session code ⁷.

Limitations

• Unreachable memory. SSD controller DRAM sits on a private bus that host commands cannot access ⁶. Amodo's code notes that overwriting by logical block address cannot reach over-provisioned or remapped blocks either ⁷. The optimized algorithm's 25 GiB of working memory is "supposedly wiped but isn't attested" ⁶. Amodo lists many other stores in a GB200 system and asks how network-switch memory could be wiped ⁵.
• Outside help. In data centres, remote memory round trips of about 1–2 µs compare with about 70–200 ns for local DRAM, which the MIRI overview puts at roughly a tenfold timing margin ⁴. Evasion by pre-staging data is closed only by unpredictable, capacity-filling challenges ⁴.
• Downtime. Filling a pod's volatile memory takes tens of minutes, and SSDs take hours ⁴.
• Residual gap. Memory between the erased region and full capacity could hold data ³. Bursuc et al. say that closing this gap needs future work ³.