{"id":"2e8013d1-4200-45a0-b3d4-c66991342b48","arxiv_id":"2509.10224","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"No single software-based memory-erasure protocol wins in every IoT setting; the best choice depends on device speed, memory size, network cost, and the required security level.","lead":"Researchers implemented seven software-based memory-erasure protocols on three off-the-shelf IoT microcontrollers and measured how long each one takes to wipe memory and prove it. The study offers device makers a data-driven way to pick the best protocol for their hardware, memory size, and security needs.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Partial-memory benchmark (2–8 KB fixed array) underpins the protocol-selection framework, so its full-memory recommendations are an untested extrapolation.","rationale":"The reader's conditional verdict is appropriate; I do not move it. The timing data are a real contribution and appear internally consistent (the repository link is provided). The load-bearing weakness is not the measurements themselves but their interpretation: the framework in Table 11 outputs a single winning protocol for combinations of network cost, clock speed, memory size, and security level, yet the memory-size dimension was only exercised up to 8 KB on one device and 2 KB on the slower devices. Section 4.3 itself says further experiments are needed to find the threshold where DFKP degrades, which is precisely the regime the framework labels 'large memory.' Because the authors' own PoSE protocols are labelled 'high security' in Tables 11–12, an independent check of those labels would also strengthen the framework, but the partial-memory extrapolation is the more basic threat to the central claim. A full-memory benchmark on the slower devices would settle whether the concern actually lands.","tokens_in":13481,"tokens_out":4145,"duration_ms":37750,"concrete_test":"Re-run the seven protocol implementations on FR5994 and F5529 with the erased array sized to the device's full data memory (8 KB and 10 KB respectively), placing the array via a device-specific linker script so stack and protocol code remain intact. Compare completion times and failure rates against the reported 2 KB results and against linear extrapolation; if any protocol fails to complete or timings grow faster than linear, the framework's full-memory recommendations are unsupported, whereas matching linear scaling would resolve the concern.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central empirical claim and the selection framework in Table 11 depend on the 'memory size' dimension, but all measurements erase a fixed compile-time array of only 2 KB on F5529/FR5994 and 2–8 KB on CC2652, against data memories of 10, 8, and 88 KB (Table 2). Section 3.4 explicitly concedes that increasing the array risks overwriting memory used during execution and that the implementations 'are limited to performance testing.' The only scaling experiment (Section 4.3) stops at 8 KB on one device, so the framework's 'large vs. small memory' recommendations have no supporting data at full-memory sizes. This matters because complexity differences are exactly what should appear at larger n: DFKP is quadratic while PoSE variants are linear, and on the slow F5529 the best-case erasure of 2 KB already takes 31.1 s (PoSEgraph/blake3, Table 10); a linearly extrapolated full 10 KB erase would take over 2.5 minutes, and superlinear behaviour would make it worse. The headline feasibility claim and the protocol rankings therefore rest on an untested extrapolation, not on full-memory measurements.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper reports the first comparative empirical evaluation of seven software-based memory-erasure protocols on three low-cost IoT microcontrollers, measuring erasure time, total execution time, memory footprint, and communication cost across several hash function implementations. The authors conclude that the protocols are feasible in practice, that no single protocol dominates across all settings, and they propose a decision framework (Table 11) that chooses the most performant protocol for a given combination of network cost, clock speed, memory size, and required security level. The experimental methodology, including open-source implementations, is described in enough detail to be reproduced.","tokens_in":13706,"tokens_out":4331,"duration_ms":38286,"significance":"If its conclusions are accepted, this is a useful first benchmark for a class of protocols that has mostly been studied theoretically. The paper provides open-source implementations, transparent timing measurements, and a reproducible experimental setup, which are clear strengths. The empirical non-dominance result follows from the reported timings. However, the significance is moderated by the fact that all measurements erase a small fixed array rather than the device's full memory, and the proposed selection framework extrapolates from these limited measurements to full-memory deployment scenarios.","major_comments":[{"comment":"The empirical core measures erasure of a fixed compile-time array: 2 KB on F5529 and FR5994, and 2, 4, 8 KB on CC2652, whereas the devices' data memories are 10 KB, 8 KB, and 88 KB respectively (Table 2). Section 3.4 explicitly states that the implementations are 'limited to performance testing' and would need to be adapted for deployment. Nevertheless, Table 11 is derived by 'extrapolating the behaviour of the protocols' across 'large' and 'small' memory sizes, and Section 6 concludes that 'erasing the full memory securely could take several minutes for the slower devices.' No data support these extrapolations: the only scaling experiment (Section 4.3) stops at 8 KB on one device, and because DFKP is quadratic while the PoSE variants are linear, relative rankings can change at larger memory sizes. The feasibility claim and the protocol-selection framework therefore rest on an untested extrapolation, which is load-bearing for the paper's headline conclusions.","section":"Section 3.4, Section 4.3, Table 11"},{"comment":"The security-relevant columns (Proof, Prob., No-Isolation, Erasure) and the security labels used in the decision framework are taken as claimed in the literature, with no independent verification or even a sensitivity analysis. Since three of the seven evaluated protocols are the authors' own designs from Bursuc et al., errors or contested assumptions in those original security claims would propagate directly into the recommendations of Table 11 without the paper providing any means to detect them. The paper should either verify these properties on the implementations or explicitly state that the framework inherits unverified literature claims, and it should discuss how sensitive the recommended choices are to the reliability of those labels.","section":"Section 2, Table 1, Section 5, Table 11"}],"minor_comments":[{"comment":"The text contains typos: 'FF5529' should be 'F5529' and 'sha265hw' should be 'sha256hw'.","section":"Section 4.1"},{"comment":"The sentence 'We implemented6 7 protocols' appears to be a formatting artifact from a footnote marker and reads as 'implemented 67 protocols'; it should read 'implemented 7 protocols'.","section":"Section 6"},{"comment":"The notes 'For PoSE random it was 6.8 seconds' are placed outside the table body and are easy to miss; they should be integrated into the main table or referenced clearly in the caption.","section":"Tables 9 and 10"},{"comment":"The tables report point estimates without variance, confidence intervals, or the number of repetitions. Given that Bluetooth communication can be noisy, some indication of measurement spread would strengthen the ranking conclusions and the claimed differences between protocols.","section":"Section 4"}],"recommendation":"major_revision","confidential_remarks":"The inclusion of the authors' own PoSE protocols among the evaluated protocols is not itself a problem, but the paper should make the provenance of the security labels more explicit. The main fix required is to either narrow the claims to the measured memory sizes or add full-memory experiments; otherwise the paper's central feasibility and selection claims are not supported by the data. This is within scope for the journal, and the empirical benchmark is a useful contribution once the extrapolation issue is addressed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague, quick take: this is the first common benchmark for software-based memory-erasure protocols, and that alone is a useful contribution. They implement seven protocols on three TI microcontrollers, with six hash options, measure erasure and total times, and package the results into a selection framework. Code is linked, and the setup is described in enough detail to re-implement.\n\nThe core empirical finding—no single protocol dominates once you vary device speed, memory size, network cost, and security level—holds up. They also show that hidden constants and Bluetooth costs outweigh asymptotic complexity at the tested sizes. DFKP, with quadratic complexity, beats the quasi-linear PoSE variants on a small array. That is a real, practical insight.\n\nThe main soft spot is exactly what the stress-test note flags: the benchmark erases a compile-time array of 2–8 KB, not the device's full memory, and Section 3.4 openly says the implementations are for performance testing only. The selection framework (Table 11) then makes 'large memory' recommendations at sizes no experiment covered. The paper does flag the extrapolation, so it is not deceptive, but the table cells should be labeled as extrapolations rather than direct results. Ideally they run one larger-memory point on the CC2652 to anchor the trend.\n\nSecond, the abstract says erasure takes 'several seconds,' but the slowest measured full run is 31.1 seconds for a 2 KB erase on the F5529 (PoSEgraph, blake3). The conclusion correctly says full-memory erasure could take several minutes. The abstract understates the cost, which matters for anyone skim-reading—fix that.\n\nThird, the security columns in the comparison tables are taken from the literature, not independently verified. Since three of the seven protocols are the authors' own PoSE designs, there's a mild self-preference risk in the security/performance coupling. It doesn't invalidate the timing data, but an independent look at the security labels would strengthen confidence.\n\nOverall: the empirical core is sound, the contribution is new, and the limitations are acknowledged more than in most benchmark papers. I'd bring it to a reading group, I'd cite it, and I'd send it to peer review. Required revisions: reconcile the abstract with the conclusion, mark the large-memory cells as extrapolated, and be explicit that the benchmark does not erase full device memory.","headline":"The first side-by-side empirical benchmark of memory-erasure protocols, with real data and a no-dominance result that mostly holds up; worth publishing after the authors fix the abstraction mismatch and label the full-memory extrapolations.","tokens_in":14220,"tokens_out":2256,"would_cite":true,"duration_ms":21129,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Memory erasure on cheap IoT devices is feasible—but no protocol wins","keywords":["memory erasure","IoT security","malware removal","proof of erasure","empirical evaluation","constrained devices","hash functions","security protocols"],"falsifier":"Run the same seven protocols on the same three devices while erasing the full data memory (10–88 KB) with a deployment-ready implementation; if the relative ranking of protocols changes—for example, if a protocol labelled fastest stops being fastest—the framework's practical recommendation loses support.","tokens_in":13279,"feed_emoji":"🧹","tokens_out":8534,"duration_ms":64391,"temperature":0.7,"pith_summary":"This paper is the first head-to-head empirical comparison of software-based memory-erasure protocols on real low-cost IoT hardware, where a verifier tells a constrained device to overwrite its memory and send back a proof. The authors implemented seven protocols across three off-the-shelf microcontrollers, each combined with six hash-function implementations, and measured how long each combination takes to erase a fixed block of memory and produce a proof. The paper's central claim is that these protocols are practically feasible: even slow devices complete erasure, though they may take several seconds to more than two minutes. The measurements show that no protocol dominates every setting—the fastest choice depends on device clock speed, memory size, network cost, and the desired security level. On this basis the paper offers a decision framework that, given a target security level, selects the protocol with the best performance-and-guarantee trade-off.","feed_headline":"Memory erasure on cheap IoT devices is feasible—but no protocol wins","feed_subtitle":"Seven protocols, three microcontrollers, six hashes: which is fastest depends on network, clock, and memory.","key_machinery":"The central objects are the seven implemented protocols, which span three design families: graph-labelling functions (DFKP, KK, PoSEgraph), hash-based filling (KL, PoSElight), and verifier-sent random nonces (PT, PoSErandom). The evaluation machinery is a portable C implementation of each protocol on three microcontrollers, compiled for code size, communicating with a laptop verifier over Bluetooth, with six hash functions including hardware-accelerated AES and SHA-256 variants. Each run erases a fixed compile-time array of 2–8 KB, and the PoSE protocols use a round-trip parameter r=71, fixing their erasure guarantee at 90% with failure probability $10^{-3}$. The setup separates erasure time from verification time and splits total time into computation versus communication, which is what exposes the unexpectedly large role of network cost and hidden constants.","core_discovery":"The paper establishes that software-based memory-erasure protocols—two-party protocols in which a verifier instructs a constrained device to overwrite its memory with random data and return a proof of erasure—run successfully on unmodified low-cost microcontrollers without secure hardware. With seven protocol implementations, six hash functions, and three devices of different computational capability, every tested combination completed the erasure and proof-generation phases. Performance, however, was highly environment-dependent: total execution times ranged from under a second to more than two minutes, and network speed plus hidden constants in the protocol specifications often influenced running time more than asymptotic complexity did. The paper concludes that no protocol is universally best and presents a framework that, for a given security level, identifies which protocol offers the best trade-off between performance and erasure guarantees.","pith_inferences":["The fixed-array benchmark means the framework's rankings are validated only for partial-memory erasure; if full-memory erasure scales the computation component, graph-based protocols with larger constants may fall further behind, while random-nonce protocols would only see larger messages.","The finding that hardware-accelerated hashing was not always faster suggests that accelerator driver overhead can outweigh raw speed; a natural test is to repeat the measurements with different driver versions or hash implementations on the same accelerator.","Since network cost proved so influential, an implicit design lesson is to reduce the number of round trips rather than the byte size of messages, especially on devices whose Bluetooth stack adds fixed per-message overhead.","The paper's decision framework could be turned into a predictive model by fitting the measured time curves to memory size and network parameters, then using the fitted model to extrapolate beyond the tested 8 KB limit."],"forward_implications":["Deployers can stop relying on asymptotic complexity alone; the paper's decision table maps network cost, clock speed, memory size, and security level to the fastest protocol.","Because hash choice can change execution time by an order of magnitude or more, benchmarking several hash implementations on the target hardware becomes a necessary pre-deployment step.","Protocols that send the full memory contents over the network (PT, PoSErandom) are only competitive when network cost is low, so communication-heavy designs should be avoided on Bluetooth stacks with high per-message overhead.","DFKP's quadratic complexity does not stop it from being fastest on small memories, but its advantage erodes as memory grows, implying a crossover point beyond the tested 8 KB where other protocols take over.","For high-security requirements, PoSElight stands out as the only protocol with a formal proof, bounded attacker success probability, no-isolation resistance, and no poor performance rating on any measured feature."],"supporting_citations":[{"why":"Introduces the PT protocol, the random-nonce baseline implemented and timed in the study.","marker":"[Perito and Tsudik, 2010]"},{"why":"Introduces the KL protocol and reports its performance on off-the-shelf devices, which this study extends to a head-to-head comparison.","marker":"[Karame and Li, 2015]"},{"why":"Introduces the DFKP graph-labelling protocol whose quadratic complexity the experiments test against lower-complexity designs.","marker":"[Dziembowski et al., 2011]"},{"why":"Introduces the KK protocol with quasilinear labelling and the 1/32 erasure guarantee, a key low-guarantee comparison point.","marker":"[Karvelas and Kiayias, 2014]"},{"why":"Defines PoSEgraph and PoSErandom, the high-security no-isolation protocols whose performance with r=71 is measured.","marker":"[Bursuc et al., 2024a]"},{"why":"Defines PoSElight, the only protocol in the study that avoids a poor performance rating on every feature measured.","marker":"[Bursuc et al., 2024b]"},{"why":"Introduces SPEED, whose reliance on an unspecified Trusted Software Module led the authors to exclude it and shapes the protocol-selection criteria.","marker":"[Ammar et al., 2018]"},{"why":"Introduces the distance-bounding TR protocol, excluded for being specified symbolically, informing which protocols were implementable.","marker":"[Trujillo-Rasua, 2019]"}],"fun_headline_variants":["Memory erasure on IoT: feasible, but no universal winner","No dominant protocol in first empirical test of memory erasure","Memory erasure on IoT devices: all work, but speed varies","Network speed decides winner among memory-erasure protocols"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing assumption is that erasing a fixed compile-time array of 2–8 KB is representative of real full-memory erasure, which the paper itself flags by noting the implementations are limited to performance testing and would need adaptation for deployment.","fun_headline_variants_meta":{"raw":{"variants":["Memory erasure on IoT: feasible, but no universal winner","No dominant protocol in first empirical test of memory erasure","Memory erasure on IoT devices: all work, but speed varies","Network speed decides winner among memory-erasure protocols"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000571,"raw_usage":{"total_tokens":2709,"prompt_tokens":962,"completion_tokens":1747,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":578,"completion_tokens_details":{"reasoning_tokens":1679}},"tokens_in":578,"tokens_out":1747,"duration_ms":10776,"temperature":1.0,"reasoning_tokens":1679,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T15:56:19.274123+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same seven protocols on the same three devices while erasing the full data memory (10–88 KB) with a deployment-ready implementation; if the relative ranking of protocols changes—for example, if a protocol labelled fastest stops being fastest—the framework's practical recommendation loses support.","supporting_citations":[{"cited_title":"and Tsudik, G","cited_arxiv_id":null,"evidence_quote":"Introduces the PT protocol, the random-nonce baseline implemented and timed in the study."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces the KL protocol and reports its performance on off-the-shelf devices, which this study extends to a head-to-head comparison."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces the DFKP graph-labelling protocol whose quadratic complexity the experiments test against lower-complexity designs."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces the KK protocol with quasilinear labelling and the 1/32 erasure guarantee, a key low-guarantee comparison point."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces SPEED, whose reliance on an unspecified Trusted Software Module led the authors to exclude it and shapes the protocol-selection criteria."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces the distance-bounding TR protocol, excluded for being specified symbolically, informing which protocols were implementable."}],"review_version":1}