{ "schema_version": "1.0.0", "rubric_version": "1.0", "license": "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)", "record": { "id": "M-0016", "slug": "timed-challenge-response", "title": "Timed challenge-response and memory-occupation challenges", "aliases": [ "Memory challenges", "Memory-occupation challenges", "Software-based attestation", "Proof-of-space-style challenges" ], "status": "draft", "last_reviewed": "2026-09-23", "review_interval_days": 90, "steward": null, "provenance": { "drafted_by": "ai", "reviewed_by": [] }, "risk_flags": [], "flags": [], "one_liner": "A verifier sends unpredictable questions that a device can answer in time only if it holds specified data, or dedicates specified resources, locally.", "summary": "In a timed challenge, a verifier sends an unpredictable question that a device can answer in time only if it holds certain data locally or dedicates certain resources to the answer. Filling a device's memory with verifier-chosen data and then checking random pieces can bound how much spare memory it has. The approach builds on software-based attestation of embedded devices and on proofs of space. AI-specific public work is thin: one design overview, one study showing that response times reveal whether data sits in an H100's memory, and memory-wiping designs that use such challenges. As of September 2026, no network-level test across data-centre servers has been reported. The main obstacle is excluding outside help, such as fast remote memory. Timing-based attestation of embedded devices has been broken in practice, and its attackers judged it \"very difficult, if not impossible, to design correctly\".", "category": "cryptographic-computational", "secondary_categories": [ "accounting-provenance" ], "verifies": [ { "claim": "C-0003", "role": "primary", "note": "Compute and memory probes can reveal whether a GPU is engaged in other work (S-0033)." }, { "claim": "C-0004", "role": "supporting", "note": "Listed as an alternative inference-verification direction that may not need a hardware retrofit (S-0067); bounds spare memory (S-0018)." }, { "claim": "C-0002", "role": "supporting", "note": "Speed-of-light bounds on signed challenge round trips underlie delay-based location checks; see M-0018." } ], "threat_model": "adversarial", "adversarial_evaluation": "analysis", "hardware_requirement": "none", "prover_cooperation": "required", "confidentiality": "preserving", "depends_on": [ { "target": "M-0014", "note": "Excluding remote memory during challenges may need physical disconnection or isolation of the device group." } ], "readiness": { "assessment": true, "level": "R1", "rubric_version": "1.0", "rationale": "R1: the AI use is described and the primitives are peer-reviewed, but the only GPU experiment tests data residency on one GPU, not a memory bound across servers.\n\n- **R1** met: the MIRI overview describes memory challenges for verifying the presence of information and the absence of free memory, with timing figures and assumptions [[S-0018]]. The AI 2040 plan names memory-challenge verification as a possible direction [[S-0067]]. The underlying primitives (timed attestation, proofs of space and proofs of secure erasure) are peer-reviewed [[S-1307]] [[S-1607]] [[S-1304]].\n- **R2** not met: Monfared et al. report H100 experiments in which a VRAM-residency challenge separates data in GPU memory from data in host memory by more than 350 ms [[S-0033]]. That is a single-GPU residency test without quantified error rates, not a challenge that bounds free memory across servers [[S-0033]]; no code is linked, which the rubric does not require. The MIRI overview states that, to its author's knowledge, a network-level timing probe of memory contents between servers \"has not yet been demonstrated\" [[S-0018]]. SAGE shows timed software attestation on A100 GPUs for trusted execution, not for bounding spare capacity [[S-1306]]. The mechanism's only implementation, [[I-0012]], is a proposed architecture at R1.\n\nConfidence is low because AI-specific public sources are thin, and the narrow use of checking that data is resident in one GPU's memory may merit R2 on the H100 result alone.", "evidence": [ "S-0018", "S-0067", "S-0033", "S-1306", "S-1307", "S-1607", "S-1304" ], "next_level_gaps": [ "A network-level challenge that bounds free memory across accelerator servers, with public code or measurements described in enough detail to repeat.", "Quantified false-positive and false-negative rates under adversarial conditions.", "Evaluation against known attack classes on timed attestation, such as compression and relocation." ], "confidence": "low", "assessed_by": [ "ai-draft" ], "assessed_on": "2026-09-23", "status": "current", "dispute": null }, "flaws": [ { "assessment": true, "title": "Timing-based software attestation has been broken in practice", "kind": "demonstrated-attack", "severity": "significant", "status": "open", "description": "Castelluccia et al. implemented two generic attacks, one based on a return-oriented rootkit and one on code compression, together with specific attacks on SWATT and ICE-based schemes, on commodity sensor nodes. They conclude that secure time-based attestation is \"very difficult, if not impossible, to design correctly\". The attacks target embedded schemes, not AI accelerators.", "sources": [ "S-1308" ], "response": null }, { "assessment": true, "title": "Remote memory narrows the timing margin", "kind": "theoretical-argument", "severity": "significant", "status": "open", "description": "Data-centre remote memory access returns in about 1–2 µs, against about 70–200 ns for local DRAM. The MIRI overview says verification of memory saturation depends on ruling out remote access by latency or physical disconnection. It adds that pre-staging data is ruled out only by unpredictable, capacity-filling challenges.", "sources": [ "S-0018" ], "response": null }, { "assessment": true, "title": "Error rates not quantified", "kind": "open-question", "severity": "minor", "status": "open", "description": "Monfared et al. show separable timing distributions but do not define thresholds or statistical tests, so false-positive and false-negative rates are not quantified.", "sources": [ "S-0033" ], "response": null } ], "blockers": [ { "text": "No network-level memory challenge across data-centre servers has been demonstrated.", "theme": "adversarial-validation", "blocked_by": null, "sources": [ "S-0018" ] }, { "text": "Challenges that fill memory displace workloads; filling a pod's volatile memory takes tens of minutes and SSDs take hours.", "theme": "performance-compatibility", "blocked_by": null, "sources": [ "S-0018", "S-0033" ] }, { "text": "Outside help, such as remote memory, must be excluded during challenges.", "theme": "coverage-hidden-compute", "blocked_by": "M-0014", "sources": [ "S-0018" ] } ], "challenge_themes": [ "capacity-bounds", "coverage-hidden-compute", "protocol-soundness", "adversarial-validation", "performance-compatibility" ], "organizations": [ "O-0101", "O-0202" ], "people": [], "sources": [ { "source": "S-0018", "supports": "memory challenging for presence and absence; response-time domains; latencies; fill times; RDMA caveat; pre-staging; not yet demonstrated at network level", "locator": "§5.1.2" }, { "source": "S-0067", "supports": "memory-challenge verification and low-latency challenges as alternative directions", "locator": "verification overview; other promising directions" }, { "source": "S-0033", "supports": "PoW, VDF, GEMM and VRAM-residency probes; H100 result; threat model; overhead; FP/FN caveat", "locator": "abstract; §4–§6; limitations" }, { "source": "S-1306", "supports": "software-based attestation on A100 GPUs", "locator": "abstract" }, { "source": "S-1307", "supports": "timed checksum attestation; verifier knowledge requirements", "locator": "abstract; design sections" }, { "source": "S-1308", "supports": "demonstrated attacks on timed attestation; conclusions", "locator": "abstract; §3–§5" }, { "source": "S-1607", "supports": "proofs of space: dedicating disk space instead of computation; construction", "locator": "abstract" }, { "source": "S-0032", "supports": "timed rounds with a round-trip bound in PoSE", "locator": "§3" }, { "source": "S-1302", "supports": "challenge phase of a PoSE implementation; 1 ms RTT assumption", "locator": "protocol section" }, { "source": "S-1304", "supports": "peer-reviewed proofs of secure erasure; weaknesses of timed software attestation as motivation", "locator": "abstract" } ], "concepts": [ "K-0012", "K-0011", "K-0016", "K-0001", "K-0002", "K-0018", "K-0020" ], "complements": [ "M-0015", "M-0013" ], "alternatives": [ "M-0010" ], "type": "mechanism", "implementations": [ { "id": "I-0012", "title": "Low-trust AI compute verification system overview", "url": "https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/" } ], "url": "https://trustbutveri.fyi/mechanisms/timed-challenge-response/", "source_file": "content/mechanisms/timed-challenge-response.md", "flags_all": [ "ai-drafted" ], "body_markdown": "## How it works\n\nA timed challenge asks a device something it can answer correctly, within a deadline, only if it holds certain data locally or dedicates certain resources to the answer [[S-1307]] [[S-0018]] [[S-0033]]. Three families of primitives exist:\n\n- **Timed attestation.** In SWATT, the verifier sends a random seed, and the device computes a checksum over its memory in a pseudorandom order [[S-1307]]. If memory has been altered, the extra work shows up as a detectable delay [[S-1307]].\n- **Proofs of space.** A prover shows that it dedicates \"a significant amount of disk space as opposed to computation\" [[S-1607]]. Constructions use graphs that are hard to pebble, and Merkle hash trees [[S-1607]].\n- **Proofs of secure erasure.** These fill memory and then run timed rounds, accepting only answers that arrive within a round-trip bound [[S-0032]] [[S-1302]]; see [[M-0015]].\n\nFor AI facilities, the MIRI system overview describes two uses of memory challenges: \"A) verifying presence of information B) verifying the absence of free memory/storage\" [[S-0018]]. Response time is the main evidence, because answering from another device is measurably slower [[S-0018]]. The overview cites average NVMe read latencies of a few microseconds against about 100 ns for DRAM [[S-0018]]. For the absence case, incompressible data is loaded until capacity is full, and random samples are challenged [[S-0018]].\n\nMonfared et al. propose four GPU probes [[S-0033]]:\n\n- memory-hard puzzles inspired by proof of work, which reveal parallel effort;\n- verifiable-delay-function workloads, which measure sequential execution;\n- matrix-multiplication timing, which reflects tensor-core performance;\n- a VRAM-residency test.\n\nIn the residency test, a large challenge dataset is loaded into GPU memory [[S-0033]]. At random times, fresh challenges require keyed, memory-hard computation over it, and response times show whether it is still resident [[S-0033]].\n\n## What it establishes\nA capacity-filling challenge that is answered on time bounds how much free memory a device had at that moment [[S-0018]]. Monfared et al. argue that timing variations can expose GPU engagement, complementing other accountability mechanisms [[S-0033]]; see [[C-0003]]. The AI 2040 plan says memory-challenge verification \"has the promise of potentially also not requiring a hardware retrofit, but seems likely to face some difficulties with verifying completeness\" [[S-0067]].\n\nA presence check does not show that nothing else is stored [[S-0018]]. The overview notes that data could be pre-staged into local memory before a challenge, which only an unpredictable, capacity-filling challenge rules out [[S-0018]].\n\n## Threat model\n- **Known device.** SWATT's verifier must know the device's clock speed, instruction set, memory architecture and expected memory contents [[S-1307]].\n- **Cryptographic model.** Proofs of space are proved secure in the random oracle model, with one additional mild assumption [[S-1607]].\n- **Compromised stack.** Monfared et al. consider host and GPU firmware that \"may be modified, virtualized, or colluding\" [[S-0033]].\n- **No remote helpers.** In data centres, remote memory access is the key helper to exclude [[S-0018]]. Its round trips of about 1–2 µs compare with about 70–200 ns for local DRAM, and the overview says verification \"depends on the ability to rule out RDMA, either via response latency or physical disconnection\" [[S-0018]].\n\n## Evidence\n- **GPU memory residency.** On an H100 with a 60 GB challenge dataset, Monfared et al. report that the gap between memory-resident and host-resident responses \"exceeds 350 ms, making them trivial to distinguish\" [[S-0033]]. Their experiments ran on NVIDIA Turing and Hopper GPUs, and they do not quantify error rates [[S-0033]].\n- **GPU attestation.** SAGE, a peer-reviewed software-based attestation mechanism for A100 GPUs, is reported by its authors to be \"already practical today\" for trustworthy execution without special hardware support [[S-1306]].\n- **Memory wiping.** Amodo's wiping design includes a timed challenge phase with an assumed 1 ms round trip [[S-1302]].\n- **Across servers.** The MIRI overview states that, to its author's knowledge, distinguishing memory contents between servers with a network-level timing probe \"has not yet been demonstrated\" [[S-0018]].\n\n## Limitations\n- **Broken embedded schemes.** Castelluccia et al. implemented attacks based on a return-oriented rootkit and on code compression, together with specific attacks on SWATT and ICE-based schemes [[S-1308]]. They conclude that secure time-based attestation is \"very difficult, if not impossible, to design correctly\" [[S-1308]]. Perito and Tsudik cite such weaknesses as motivation for proofs of secure erasure [[S-1304]].\n- **Coverage.** Castelluccia et al. argue that \"all memories (RAM, ROM, EEPROM) have to be attested\" [[S-1308]].\n- **Overhead.** The VRAM-residency test \"intentionally incurs substantial memory overhead\" [[S-0033]], and filling a pod's volatile memory takes tens of minutes [[S-0018]].\n- **Unquantified error rates.** Monfared et al. do not define thresholds or statistical tests [[S-0033]].", "body_text": "How it works A timed challenge asks a device something it can answer correctly, within a deadline, only if it holds certain data locally or dedicates certain resources to the answer [S-1307] [S-0018] [S-0033]. Three families of primitives exist: - Timed attestation. In SWATT, the verifier sends a random seed, and the device computes a checksum over its memory in a pseudorandom order [S-1307]. If memory has been altered, the extra work shows up as a detectable delay [S-1307]. - Proofs of space. A prover shows that it dedicates \"a significant amount of disk space as opposed to computation\" [S-1607]. Constructions use graphs that are hard to pebble, and Merkle hash trees [S-1607]. - Proofs of secure erasure. These fill memory and then run timed rounds, accepting only answers that arrive within a round-trip bound [S-0032] [S-1302]; see Memory wiping and proofs of secure erasure. For AI facilities, the MIRI system overview describes two uses of memory challenges: \"A) verifying presence of information B) verifying the absence of free memory/storage\" [S-0018]. Response time is the main evidence, because answering from another device is measurably slower [S-0018]. The overview cites average NVMe read latencies of a few microseconds against about 100 ns for DRAM [S-0018]. For the absence case, incompressible data is loaded until capacity is full, and random samples are challenged [S-0018]. Monfared et al. propose four GPU probes [S-0033]: - memory-hard puzzles inspired by proof of work, which reveal parallel effort; - verifiable-delay-function workloads, which measure sequential execution; - matrix-multiplication timing, which reflects tensor-core performance; - a VRAM-residency test. In the residency test, a large challenge dataset is loaded into GPU memory [S-0033]. At random times, fresh challenges require keyed, memory-hard computation over it, and response times show whether it is still resident [S-0033]. What it establishes A capacity-filling challenge that is answered on time bounds how much free memory a device had at that moment [S-0018]. Monfared et al. argue that timing variations can expose GPU engagement, complementing other accountability mechanisms [S-0033]; see Declared hardware is idle or shut down. The AI 2040 plan says memory-challenge verification \"has the promise of potentially also not requiring a hardware retrofit, but seems likely to face some difficulties with verifying completeness\" [S-0067]. A presence check does not show that nothing else is stored [S-0018]. The overview notes that data could be pre-staged into local memory before a challenge, which only an unpredictable, capacity-filling challenge rules out [S-0018]. Threat model - Known device. SWATT's verifier must know the device's clock speed, instruction set, memory architecture and expected memory contents [S-1307]. - Cryptographic model. Proofs of space are proved secure in the random oracle model, with one additional mild assumption [S-1607]. - Compromised stack. Monfared et al. consider host and GPU firmware that \"may be modified, virtualized, or colluding\" [S-0033]. - No remote helpers. In data centres, remote memory access is the key helper to exclude [S-0018]. Its round trips of about 1–2 µs compare with about 70–200 ns for local DRAM, and the overview says verification \"depends on the ability to rule out RDMA, either via response latency or physical disconnection\" [S-0018]. Evidence - GPU memory residency. On an H100 with a 60 GB challenge dataset, Monfared et al. report that the gap between memory-resident and host-resident responses \"exceeds 350 ms, making them trivial to distinguish\" [S-0033]. Their experiments ran on NVIDIA Turing and Hopper GPUs, and they do not quantify error rates [S-0033]. - GPU attestation. SAGE, a peer-reviewed software-based attestation mechanism for A100 GPUs, is reported by its authors to be \"already practical today\" for trustworthy execution without special hardware support [S-1306]. - Memory wiping. Amodo's wiping design includes a timed challenge phase with an assumed 1 ms round trip [S-1302]. - Across servers. The MIRI overview states that, to its author's knowledge, distinguishing memory contents between servers with a network-level timing probe \"has not yet been demonstrated\" [S-0018]. Limitations - Broken embedded schemes. Castelluccia et al. implemented attacks based on a return-oriented rootkit and on code compression, together with specific attacks on SWATT and ICE-based schemes [S-1308]. They conclude that secure time-based attestation is \"very difficult, if not impossible, to design correctly\" [S-1308]. Perito and Tsudik cite such weaknesses as motivation for proofs of secure erasure [S-1304]. - Coverage. Castelluccia et al. argue that \"all memories (RAM, ROM, EEPROM) have to be attested\" [S-1308]. - Overhead. The VRAM-residency test \"intentionally incurs substantial memory overhead\" [S-0033], and filling a pod's volatile memory takes tens of minutes [S-0018]. - Unquantified error rates. Monfared et al. do not define thresholds or statistical tests [S-0033].", "referenced_by": [ { "id": "M-0014", "title": "Bandwidth limits and compartmentalization", "url": "https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/" }, { "id": "M-0018", "title": "Chip location verification", "url": "https://trustbutveri.fyi/mechanisms/chip-location-verification/" }, { "id": "M-0015", "title": "Memory wiping and proofs of secure erasure", "url": "https://trustbutveri.fyi/mechanisms/memory-wiping-and-secure-erasure/" }, { "id": "M-0013", "title": "Network taps and certifiers", "url": "https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/" }, { "id": "M-0010", "title": "On-chip telemetry from timing, memory and performance counters", "url": "https://trustbutveri.fyi/mechanisms/on-chip-telemetry/" }, { "id": "I-0012", "title": "Low-trust AI compute verification system overview", "url": "https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/" }, { "id": "C-0003", "title": "Declared hardware is idle or shut down", "url": "https://trustbutveri.fyi/claims/declared-hardware-is-idle/" }, { "id": "K-0012", "title": "Proof of space", "url": "https://trustbutveri.fyi/concepts/proof-of-space/" }, { "id": "O-0202", "title": "Machine Intelligence Research Institute", "url": "https://trustbutveri.fyi/organizations/machine-intelligence-research-institute/" } ] } }