{"id":"ae47aee9-8466-4c69-9817-5722219d792f","arxiv_id":"2508.10429","paper_version":1,"verdict":"UNVERDICTED","confidence":"LOW","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"No support is provided for the claimed MM-Food-100K dataset because the full text is an unrelated security analysis showing a MIRAGE AES attack disappears when eviction seeds are randomized.","lead":"The submission's abstract describes a 100K food dataset with provenance ledgers, but its full text is a separate paper on MIRAGE cache side-channel attacks. That body paper finds a published AES key recovery attack on MIRAGE was a simulation artifact caused by a fixed random seed.","discovery_kind":"replication","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Debunking depends on unverified reset/predict assumptions for MIRAGE's eviction RNG; per-run random seeding is not shown to match real hardware.","rationale":"The paper provides a valuable reproduction and identifies real bugs (GE trace counting, fixed eviction seed) in RCO's artifact. The fixed-seed diagnosis is well-supported by the histograms in Fig. 3, and the open-source code is a strength. However, the decisive step is the reinterpretation of the artifact's fixed seed as an unrealistic modeling choice. That step is an assumption about the attacker's capabilities relative to MIRAGE's RNG, not a demonstrated property of the design. The paper does not cite or analyze the RNG implementation in [1], nor does it argue that the RNG state cannot be observed or synchronized. The `std::random_device` caveat adds a second, narrower assumption. Therefore the broad conclusion 'MIRAGE remains resilient' is conditional on these assumptions. Since the submitted manuscript is already internally incoherent (front matter describing MM-Food-100K vs. body on MIRAGE), no accept/reject is possible; the reader's UNVERDICTED status is appropriate. My concern further supports caution but does not change that overall verdict, so I recommend UNCHANGED.","tokens_in":7641,"tokens_out":7645,"duration_ms":81461,"concrete_test":"Run the RCO artifact in a single continuous simulation: initialize the simulator once with a random seed, and process all AES encryptions in one process without re-seeding the eviction RNG or resetting the cache state between traces (so the RNG state carries over, as in real hardware). If guessing entropy drops below 90% under this continuous-RNG model, the per-trace independent randomization used in the debunking is not representative, and the conclusion needs reassessment. Additionally, log the seeds produced by `std::random_device` on the evaluation machine across thousands of invocations to verify they are distinct and high-entropy; repeated or predictable seeds would invalidate the fix.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim—that RCO's AES leakage is a simulation artifact caused by a fixed eviction RNG seed—rests on the 'fix' in Sec. III-A and App. B: replacing the constant seed 42 with a fresh `std::random_device` seed before every AES run. This is only a faithful model if, in real MIRAGE hardware, an attacker can neither reset nor predict the global-eviction RNG state between traces. The paper asserts this ('the attacker cannot reset the RNG to a constant state') but provides no analysis of MIRAGE's RNG implementation or threat model. If the RNG uses a predictable PRNG and the attacker can synchronize to its state (e.g., by observing evictions or triggering resets), the deterministic correlation exploited by RCO could return, and the 'random-seed' fix would be hiding, not removing, the vulnerability. The reliance on `std::random_device` is also fragile: the authors' own footnote 3 notes it can be deterministic on some systems. If the evaluation platform's `std::random_device` is not a hardware entropy source, the 'random' seeds may themselves be predictable or repetitive, so the absence of leakage would not reflect a realistic adversary. Thus the negative result is conditional on unvalidated assumptions about RNG state control and entropy quality.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The body of the manuscript is a short critique of the SEC'25 paper \"Systematic Evaluation of Randomized Cache Designs against Cache Occupancy\" (RCO). The authors reproduce RCO's AES key-recovery experiment on the MIRAGE randomized cache using the released artifact and identify two bugs. The first (Appendix A) is a guessing-entropy (GE) analysis bug: RCO's code enforces max_traces per trace file rather than across all trace files, so it uses roughly 6x more traces than intended, under-reporting the number of traces needed to reach a given GE. The second (Appendix B) is a modeling bug: RCO initializes MIRAGE's global-eviction RNG with a fixed seed (42) before each AES run, producing a deterministic eviction sequence across runs. The authors patch the artifact to use a per-run random seed, observe that the correlation between victim key-byte accesses and attacker timings disappears, and report GE remaining above 90% after thousands of traces. They conclude that RCO's claimed AES key leakage from MIRAGE is a simulation artifact, not a real vulnerability. The paper's front matter, however, is inconsistent with the body: the title and abstract describe a food-image dataset (MM-Food-100K), not the MIRAGE security analysis.","tokens_in":7918,"tokens_out":6023,"duration_ms":75044,"significance":"If the technical claims hold, this is a significant correction to the randomized-cache side-channel literature. The paper is useful because it ships an open-source reproduction, pinpoints a concrete code-level bug (the per-file max_traces error), and demonstrates with a minimal patch that the fixed-seed modeling choice can create artificial correlations. The GE bug in Appendix A is convincingly documented with a diff and explains the discrepancy between RCO's reported numbers and the reproduced trend. The main conceptual contribution—that the RCO attack depends on a deterministic eviction sequence—is plausible and deserves to be aired. However, the paper's strongest conclusion, that MIRAGE is not vulnerable to occupancy-based AES key recovery, is conditional on an unstated and unvalidated assumption about the adversarial controllability of MIRAGE's eviction RNG state. The evidence presented is consistent with the claim, but it does not yet establish the claim for real hardware. The manuscript also needs substantial editorial work to fix the front-matter mismatch.","major_comments":[{"comment":"The supplied title and abstract describe \"MM-Food-100K: A 100,000-Sample Multimodal Food Intelligence Dataset\" while the body is a security analysis of MIRAGE randomized caches (arXiv 2508.10431v3). This mismatch makes the manuscript impossible to evaluate as a coherent submission. The authors must reconcile the front matter with the actual content, or confirm that the wrong metadata was supplied.","section":"Abstract / front matter"},{"comment":"The central claim that randomizing the global-eviction seed \"reflects realistic operation\" is load-bearing and is not supported by any analysis of MIRAGE's RNG implementation. The paper asserts that \"the attacker cannot reset the RNG to a constant state on each AES run,\" but it does not justify this for MIRAGE: if the real eviction RNG is a predictable PRNG whose state can be observed or reset, the deterministic correlation exploited by RCO could reappear. Please provide a threat-model analysis of MIRAGE's RNG source (TRNG vs PRNG, reset behavior, attacker observability) or demonstrate robustness under adversarial seed control, e.g., repeated fixed seeds, time-derived seeds, or known PRNG states. The reliance on std::random_device is also fragile; the paper's own footnote 3 notes it can be deterministic on some systems. The evaluation should report the platform's entropy source or use a","section":"§III-A and Appendix B"},{"comment":"The quantitative evidence for \"no leakage\" is a single GE curve with no multiple trials, confidence intervals, or specification of how many random seeds, keys, and plaintexts were used. Guessing entropy, as defined in the paper (GE = Σ log2(R_i)), is measured in bits, so the repeated statement \"GE above 90%\" is ambiguous; it should be \"above 90 bits\" or \"above 90% of the 128-bit key.\" Without repeated randomized trials or worst-case adversarial seed choices, the claim that \"the attack fails\" is not statistically established.","section":"§III-C and Figure 4"},{"comment":"The paper asserts that after the seed fix, the 64KB L1 cache configuration also shows no correlation between profiled and victim key heatmaps, but no result is shown; the text only says \"we confirmed.\" Since the L1 size is presented as a second modeling concern, the corresponding result should be documented in a figure, table, or appendix.","section":"§III-B"}],"minor_comments":[{"comment":"The y-axis label is missing or cropped; please label it as \"Guessing Entropy (bits)\" and include axis ticks so readers can verify the >90-bit claim.","section":"Figure 4"},{"comment":"The bug/fix diff is clear, but it would help to add a short comment in the code showing that traces_used is incremented per trace and checked across files, to make the global limit explicit.","section":"Appendix A"},{"comment":"The observation that 100 repetitions of the same encryption produce identical access times is a check on determinism, not itself a proof of the modeling error; consider stating this explicitly so readers do not misinterpret the histogram as evidence of a separate bug.","section":"Figure 3(a)"},{"comment":"Reference [7] is a URL to cppreference.com; add an access date and, if possible, a version or commit identifier for a stable citation.","section":"References"},{"comment":"The title \"Yet Another Mirage of Breaking MIRAGE\" is informal; a more descriptive title (e.g., \"On the Impact of Eviction-RNG Seeding in Simulated MIRAGE Attacks\") would be appropriate for a journal.","section":"Title"}],"recommendation":"major_revision","confidential_remarks":"The front-matter mismatch is a serious editorial problem; I reviewed the body text as the substantive manuscript. The GE bug is well-supported, but the main debunking rests on an RNG-adversary assumption that needs to be made explicit and defended. If the authors can supply a proper threat model and additional seed-randomization experiments, the paper could become a valuable correction to the record."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe arXiv paper you flagged is two papers in a trench coat. The abstract describes MM-Food-100K, a 100K food dataset with provenance; the full text is a critique of a USENIX Security 2025 paper claiming AES key recovery on the MIRAGE randomized cache. The front matter is a separate artifact, and the body is a reproduction study by Cao and Saileshwar. Treat the body as the actual preprint.\n\nWhat's new: the body identifies a concrete, previously unreported modeling flaw in the RCO artifact: a fixed RNG seed (42) for MIRAGE's global evictions, combined with restarting the simulation per AES encryption, produces a deterministic eviction sequence across runs. That artificially correlates attacker timings with key-dependent T-table accesses. The paper also finds a separate GE-counting bug that under-reports traces needed by ~6x. Both are clearly demonstrated, and the authors ship open-source code and a patch. That is genuine, reproducible work.\n\nWhat's soft: the debunking's central argument depends on the assumption that in real MIRAGE hardware, an attacker cannot reset or predict the eviction RNG state between AES runs. The paper asserts this but provides no analysis of MIRAGE's RNG design or threat model. If the RNG is a predictable PRNG and the attacker can synchronize to it, the deterministic correlation could come back, and the 'random seed' fix would be hiding, not eliminating, the leak. Also, the fix uses std::random_device to seed mt19937; the authors footnote that random_device can be deterministic on some systems, but they don't validate their platform. So the negative result is conditional on unvalidated assumptions about RNG state control and entropy quality. The 512-byte L1 issue is a legitimate but secondary point; they show the random-seed fix works regardless.\n\nThe body reads as a solid technical note, and the GE-counting bug alone is a useful correction. But the submission itself is incoherent: the food-dataset abstract makes claims about data, fine-tuning, and provenance that cannot be evaluated from this manuscript. That's a serious submission-integrity problem.\n\nMy take: if the authors resubmit the MIRAGE critique with matching front matter, it deserves a serious referee, with the RNG modeling assumption as the key question. As submitted, it should be returned for resubmission. I wouldn't cite it yet—the core claim hasn't been validated against real hardware.\n\nBest","headline":"The body is a solid, reproducible critique of the RCO AES key recovery on MIRAGE, but the submission's front matter is a completely different food-dataset paper, and the debunking's central RNG assumption remains unvalidated.","tokens_in":8392,"tokens_out":3267,"would_cite":false,"duration_ms":36442,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A reported AES-key recovery attack on the MIRAGE cache is a simulation artifact: randomizing the eviction seed per run eliminates the leak.","keywords":["cache occupancy side channel","MIRAGE","AES key recovery","simulation artifact","global eviction RNG","randomized caches","guessing entropy"],"falsifier":"Run the released simulator with the original constant seed (42) and again with per-run random seeds, then compare attacker array-access time distributions for repeated encryptions of the same plaintext and key. If the random-seed runs still cluster into repeatable, key-correlated timing groups, the refutation fails; if they overlap with roughly 100,000-cycle spread while the fixed-seed runs collapse to identical histograms, the leakage is simulation-only. On real MIRAGE hardware, the same test settles it directly.","tokens_in":7531,"feed_emoji":"🔐","tokens_out":8087,"duration_ms":83157,"temperature":0.7,"pith_summary":"The paper sets out to show that a reported AES-key recovery attack on MIRAGE, a fully associative randomized cache, is not a real vulnerability. Reusing the attack authors' released simulator, it finds the reported leakage depends on a simulation choice: the random generator that controls MIRAGE's global evictions is re-seeded to the same constant value before every AES encryption, so each run evicts the same cache lines and timings become artificially deterministic. Once the seed is randomized per run to reflect real hardware, the correlation between AES T-table accesses and attacker-observed timings disappears, and the key's guessing entropy stays above 90% after thousands of traces. A second bug made the original paper under-report how many traces were needed, but the seed flaw is the decisive one. A sympathetic reading says MIRAGE's occupancy channel leaks far less than claimed.","feed_headline":"MIRAGE key-leak attack fails when eviction seeds go random","feed_subtitle":"A constant simulator seed made every AES run identical; randomizing it keeps guessing entropy above 90%.","key_machinery":"The load-bearing object is the pseudorandom generator MIRAGE uses for global evictions, and the seed it starts from in simulation. The original attack rests on a constant seed (mt_rand(42)) restarting every AES run; the fix seeds each run with std::random_device, giving $O \\approx f(V, R)$ rather than $O \\approx f(V)$. This formula is the central identity: cache occupancy is a function of both victim accesses and random global eviction decisions. With the seed fixed, the random term is constant and key-dependent accesses dominate; with the seed random, eviction noise overwhelms the key signal.","core_discovery":"The paper establishes that the claimed AES-key leakage on MIRAGE via cache occupancy is not a property of the hardware but an artifact of the simulator. In the attacked paper's released code, the RNG that drives MIRAGE's global evictions is initialized with a constant seed (42) at the start of every AES encryption, so each encryption follows the same deterministic eviction sequence; cache occupancy then depends on victim accesses alone, $O \\approx f(V)$, which creates a clean correlation with key-dependent T-table lookups. Randomizing the seed per encryption restores $O \\approx f(V, R)$, where $R$ is the random eviction sequence; the attacker's timing distributions spread by roughly 100,000","pith_inferences":["Beyond the paper's own conclusion, the constant-seed pattern is a general reproducibility hazard: any cache-side-channel simulator that restarts per encryption and seeds its eviction RNG once can produce deterministic traces that no real hardware would show.","The paper does not rule out occupancy attacks that exploit one long-running RNG state rather than restarting per encryption, or that use statistical denoising; it rules out this template attack's signal under realistic per-run randomness.","The refutation's strength tracks the entropy quality of the per-run seed source. On platforms where std::random_device degenerates to a predictable sequence, the practical conclusion could differ; the authors flag this caveat."],"forward_implications":["AES key recovery on MIRAGE through cache occupancy should not be treated as a hardware-level finding; a faithful simulator leaves guessing entropy above 90% after thousands of traces.","MIRAGE's core design guarantee, that conflict-based attacks cannot find set-associative evictions, is not contradicted by the reported occupancy attack.","Evaluators of future randomized-cache attacks must randomize RNG state across simulated runs; any constant-seed artifact can manufacture spurious leakage.","The same-year survey of randomized-cache security that repeats the occupancy claim needs a correction, since its figure relies on the same flawed analysis."],"supporting_citations":[{"why":"Defines MIRAGE: fully associative randomized cache with global random evictions, the design whose security is at issue.","marker":"[1]"},{"why":"Supplies the power-of-two-choices load-balancing result that MIRAGE uses to avoid set-associative evictions.","marker":"[2]"},{"why":"Earlier claimed attack on MIRAGE that was later shown to be a modeling artifact; supplies the precedent for this debunking.","marker":"[3]"},{"why":"Prior debunking of that earlier attack; establishes the methodology of examining simulator modeling choices.","marker":"[4]"},{"why":"The paper whose artifact and AES key-recovery claims are reproduced, found buggy, and corrected.","marker":"[5]"},{"why":"A same-venue survey that repeats the disputed MIRAGE occupancy-leakage claim; its conclusion is a target of the correction.","marker":"[6]"},{"why":"Documents that std::random_device may be deterministic on some systems, which bounds the fix's real-hardware fidelity.","marker":"[7]"}],"fun_headline_variants":["100K multimodal food images with verifiable provenance","Community-sourced food dataset: 100K images, traced origins","Food AI gets a 100K-image dataset with auditable sourcing","Fine-tuned food models gain from 100K verified images","Multimodal food intelligence: 100K samples, verifiable ledger"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"The whole refutation rests on the premise that MIRAGE's global-eviction randomness cannot be reset or predicted by the attacker between AES runs, so a per-run random seed is the right model; if an attacker could force or know that seed, the reported leakage could return, and the fix also assumes the chosen random source is truly random on the target system.","fun_headline_variants_meta":{"raw":{"variants":["100K multimodal food images with verifiable provenance","Community-sourced food dataset: 100K images, traced origins","Food AI gets a 100K-image dataset with auditable sourcing","Fine-tuned food models gain from 100K verified images","Multimodal food intelligence: 100K samples, verifiable ledger"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000919,"raw_usage":{"total_tokens":3780,"prompt_tokens":744,"completion_tokens":3036,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":488,"completion_tokens_details":{"reasoning_tokens":2959}},"tokens_in":488,"tokens_out":3036,"duration_ms":24844,"temperature":1.0,"reasoning_tokens":2959,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T20:26:34.683442+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the released simulator with the original constant seed (42) and again with per-run random seeds, then compare attacker array-access time distributions for repeated encryptions of the same plaintext and key. If the random-seed runs still cluster into repeatable, key-correlated timing groups, the refutation fails; if they overlap with roughly 100,000-cycle spread while the fixed-seed runs collapse to identical histograms, the leakage is simulation-only. On real MIRAGE hardware, the same test settles it directly.","supporting_citations":[{"cited_title":"(2014, September)","cited_arxiv_id":null,"evidence_quote":"Defines MIRAGE: fully associative randomized cache with global random evictions, the design whose security is at issue."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the power-of-two-choices load-balancing result that MIRAGE uses to avoid set-associative evictions."},{"cited_title":"W., Hallacy, C., Ramesh, A., Goh, G., Agarwal, S.,","cited_arxiv_id":null,"evidence_quote":"Prior debunking of that earlier attack; establishes the methodology of examining simulator modeling choices."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The paper whose artifact and AES key-recovery claims are reproduced, found buggy, and corrected."},{"cited_title":"& Murphy, K","cited_arxiv_id":null,"evidence_quote":"A same-venue survey that repeats the disputed MIRAGE occupancy-leakage claim; its conclusion is a target of the correction."},{"cited_title":"J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S.,","cited_arxiv_id":null,"evidence_quote":"Documents that std::random_device may be deterministic on some systems, which bounds the fix's real-hardware fidelity."}],"review_version":1}