{"id":"7d19c3b4-f733-48e2-bf19-57b8ab38edcf","arxiv_id":"2507.04197","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":4,"one_line_summary":"A Random Forest trained on timing and ciphertext features can detect self-injected timing and bit-flip anomalies in AES-128 better than a timing threshold, on CPU and PYNQ-Z1.","lead":"This paper injects artificial timing delays and bit flips into AES-128 encryption, then compares a Random Forest classifier with a timing threshold for detecting those injected changes on a CPU and a PYNQ FPGA board. It reports that the ML detector is more accurate and still fast enough for real-time use.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The paper's fault model makes 'faulty' ciphertexts statistically identical to normal ones under random plaintexts, so the claimed ML fault-detection accuracy must stem from feature leakage or timing, not from detecting faults.","rationale":"The reader's rejection is well-founded. My stress-test refines it: the flaw is not only that the injected faults are unrealistic; under the paper's own model they are undetectable from ciphertext features. AES with a fixed key is a permutation, and XORing a uniformly random plaintext with a constant yields another uniformly random plaintext, so the ciphertext distributions of normal and 'faulty' blocks coincide. Any reported fault-detection accuracy must come from timing delays on other samples, from including the pre-injection plaintext as a feature (Algorithm 2 Step 3), or from train/test leakage. This makes the central comparative claim—that ML outperforms threshold detection—unsupported even for the synthetic setup. The concrete fault-only test would settle whether leakage or artifact explains Table II. The additional inconsistency between the 5–20 minute sleep in Section III and the millisecond latencies in Table I reinforces that the timing measurements cannot be taken at face value. If the re-run confirms chance accuracy, no adjustment to the reader's REJECT is needed; if it reveals leakage, the correct remedy is a redesigned experiment with faults injected inside the AES state and with features limited to observable timing and ciphertext.","tokens_in":6814,"tokens_out":7268,"duration_ms":82171,"concrete_test":"Run a fault-only experiment using the paper's code path with no timing delays: generate an equal number of normal and fault-injected random 16-byte plaintext blocks under a fixed AES-128 key, extract only encryption time and ciphertext bytes as features, and train/evaluate the Random Forest on a fresh test set. If balanced accuracy is at chance (~50%), the claimed fault-detection gains in Table II are unsupported. If accuracy is substantially above chance, inspect the feature pipeline for leakage (e.g., original plaintext stored as a feature), which would explain the result.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim depends on the Random Forest's ability to detect fault-injected AES blocks from timing and ciphertext features. Under the paper's own fault model (Section III and Algorithms 1–2), a fault is simulated by XORing the first plaintext byte with 0xFF before encryption. Let P be a uniformly random 16-byte plaintext and E_K the AES-128 permutation for a fixed key K. The normal ciphertext is C = E_K(P); the 'faulty' ciphertext is C' = E_K(P XOR constant). Since XOR with a constant is a bijection, P XOR constant is also uniform over the plaintext space. Therefore C' has exactly the same marginal distribution as C. No classifier using only ciphertext bytes can distinguish a fault-injected block from a normal block. The only usable signal is the injected timing delay, which is absent for fault-only samples. Consequently, the high recall and F1 values in Table II and Figure 3 cannot be produced by a legitimate Random Forest on timing and ciphertext features. The result must rely on including the original plaintext as a feature (Algorithm 2 Step 3), which turns detection into a tautological comparison; on evaluating the training set; or on another leakage path. This is an internal correctness problem, not merely a question of whether the synthetic anomalies match real attacks. Relatedly, Section III's 5–20 minute sleep contradicts the millisecond latencies in Table I, so the timing feature itself is not consistently reported.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a framework for detecting timing and fault anomalies in AES-128 encryption, using a threshold-based timing detector and a Random Forest classifier trained on timing and ciphertext features. The authors inject synthetic anomalies—random sleeps for timing attacks and first-byte XOR for fault attacks—into a Python AES-128 ECB implementation, evaluate detection on CPU and PYNQ-Z1, and report that the ML detector outperforms the threshold method while maintaining real-time latency and low resource usage. The central claim is that the ML-based detector provides accurate, real-time anomaly detection on embedded hardware.","tokens_in":7053,"tokens_out":3923,"duration_ms":46834,"significance":"If the central claim were valid, the paper would offer a practical direction for inline anomaly detection for AES on resource-constrained FPGA platforms. The hardware implementation and latency/throughput measurements are useful to the embedded-security community, and the idea of combining timing with data features is worth exploring. However, the evaluation as presented does not support the security claim: the fault model produces ciphertexts that are statistically indistinguishable from normal ones, and the feature set explicitly includes the original plaintext, which is not available to a runtime detector. The reported detection accuracy therefore appears to be an artifact of feature leakage rather than a property of the proposed detection method. The inconsistency between the stated 5–20 minute timing delay and the measured millisecond latencies further undermines the validity of both detectors.","major_comments":[{"comment":"The fault injection model makes the 'faulty' ciphertexts statistically indistinguishable from normal ciphertexts. Because the plaintext blocks are uniformly random, XORing the first byte with 0xFF is a bijection over the plaintext space, so E_K(P XOR 0xFF) has exactly the same distribution as E_K(P). No classifier using only ciphertext bytes can detect such a fault. The high recall and F1 values in Table II must therefore derive from another source, most plausibly the 'original block bytes' feature listed in Algorithm 2 Step 3, which enables the model to compare the pre-injection plaintext with the ciphertext and effectively recover the injected label. A real detector does not have access to the original plaintext, so this feature is leakage and the reported detection accuracy does not reflect attack-detection capability. Please retrain the Random Forest without the original plaintext feature and evaluate on a fixed hold-out test set; also report what the ciphertext-only and timing-only performance actually is.","section":"Section III and Algorithm 2 Step 3"},{"comment":"The stated timing anomaly is a random sleep between 5 and 20 minutes, but Table I reports per-block latencies of approximately 0.004 seconds. If the 5–20 minute sleep were actually applied, the measured latencies would be orders of magnitude larger; if it were not applied, the 'timing anomaly' as described does not exist in the experiments. This internal contradiction makes the threshold-based timing detector and the timing feature of the ML model ill-defined, and it prevents any meaningful interpretation of the detection results.","section":"Section III-A and Table I"},{"comment":"The column labeled 'Threshold Precision' contains values greater than 1, e.g., 6.21, 11.25, which are not valid precision scores (precision is bounded between 0 and 1). This indicates either a typographical error or a different metric being reported under a misleading name. As a result, the quantitative comparison between the threshold and ML methods, including the claimed 'accuracy gain of approximately 49.15%' at 80% injection for block size 1024, is not interpretable as stated. The paper must provide the confusion matrices and explicit definitions of all reported metrics.","section":"Table II and Section V-B"}],"minor_comments":[{"comment":"The symbol '¿' appears in the condition 'if encryption time ¿ threshold'; this should be the '>' operator.","section":"Algorithm 1, line 14"},{"comment":"The threshold formula T = mean(ti) + 3× max(ti)−min(ti)/N is missing parentheses; presumably it should read mean(ti) + 3*(max(ti)-min(ti))/N, but this should be stated explicitly.","section":"Algorithm 2, line 24"},{"comment":"The table header appears to duplicate the word 'Precision' and the names of the last two columns are unclear. Please clarify whether the columns report precision, accuracy gain, or some other quantity and ensure all values are in valid ranges for the stated metric.","section":"Table II caption"},{"comment":"The in-text citations for [12] and [14] do not match the reference list: the text names 'Alawieh and Givargis' while reference [12] lists 'Alawieh and Raghunathan', and the text names 'Purnaprajna and Roy' while reference [14] lists 'Purnaprajna and Shylaja'. Please correct the citations or the reference entries.","section":"Section II and References"},{"comment":"The claim of 'real-time detection' is based on per-block encryption latency under 5 ms, but the paper does not report the end-to-end latency from anomaly occurrence to anomaly detection decision, which would include feature extraction, model inference, and threshold comparison. Please report that end-to-end latency explicitly.","section":"Section V-E"},{"comment":"The manuscript references Figure 2 and Figure 3 in Section V, but the figures themselves are not included in the submitted text. They should be provided, along with the exact data points that support the accuracy-gain and FP/FN descriptions.","section":"Figures 2 and 3"}],"recommendation":"reject","confidential_remarks":"The paper addresses a relevant problem and contains useful hardware implementation details, but the core evaluation is not scientifically valid as presented due to the indistinguishable fault model and the inclusion of the original plaintext as a feature. These issues are load-bearing for the stated security claim and cannot be fixed within the manuscript's current scope without a redesign of the experimental methodology. I see no evidence of intentional misconduct, but the current results cannot be used to support the abstract's conclusion."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a decent undergraduate-style engineering report, not a valid security result. The new bit is combining encryption timing with ciphertext byte features in a Random Forest for AES anomaly detection on PYNQ-Z1, plus a parameterized injection generator. The paper does a few things well: the system description is clear, the CPU-vs-PYNQ latency/throughput comparison is a reasonable engineering exercise, and the related-work placement is fair, including their own prior paper. The performance tables look internally plausible.\n\nThe soft spots are load-bearing. The fault model as written cannot produce the claimed accuracy. XORing the first plaintext byte with 0xFF before encryption is a bijection on the plaintext. If plaintexts are random, the 'faulty' ciphertext has exactly the same distribution as the normal ciphertext, so no classifier using timing and ciphertext alone can separate the two classes. The timing feature is absent for fault-only samples. Yet Table II and Figure 3 show high recall and F1 for fault detection. The paper explains this in Algorithm 2, Step 3: the feature set includes the original plaintext bytes. That means the classifier is literally reading the injected anomaly from the input, which is leakage, not detection. This is an internal correctness problem, not a debate about whether the synthetic anomalies match real attacks.\n\nA second inconsistency: Section III specifies timing delays of 5–20 minutes, while Table I reports latencies around 0.004 seconds and Algorithm 1 says 'short random time.' All three cannot be true, and the threshold detector and the timing feature depend on which one you believe. The reported numbers are therefore unverifiable. Table II also appears corrupted — the column labels don't match the values — and there are no error bars, code, or data.\n\nWhat is genuinely useful is the empirical PYNQ performance study: the latency and throughput numbers, and the resource usage under 30% LUT/BRAM, are plausible and could inform future work. But the security claim rests on the broken fault model, so the paper cannot stand as is. The citation pattern is normal; the related work is relevant.\n\nWho should read this: students or engineers wanting a template for timing-based monitoring on PYNQ, not security researchers. It deserves a desk reject, not referee time. If the authors redo the evaluation with a real fault model (e.g., internal computation faults, not plaintext flips), drop the plaintext features, fix the timing story, and release artifacts, it could become a legitimate workshop paper.","headline":"A clean engineering write-up with a broken fault-injection model: the reported ML detection accuracy cannot come from ciphertext features, and the timing numbers contradict themselves.","tokens_in":7628,"tokens_out":2875,"would_cite":false,"duration_ms":30582,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A Random Forest trained on timing and ciphertext features detects injected AES anomalies better than a timing threshold and runs in real time on an FPGA-based SoC.","keywords":["AES-128","anomaly detection","timing side-channel","fault injection","Random Forest","embedded security","FPGA SoC","real-time detection"],"falsifier":"Rerun the evaluation with a fault injected into the AES state during encryption (for example, a byte corrupted in round one) instead of an XOR of the first plaintext byte before encryption, and compare the Random Forest's recall against the paper's numbers; a recall drop to the threshold detector's level would show the central claim depends on the injection model rather than on general fault-detection ability.","tokens_in":6559,"feed_emoji":"🔐","tokens_out":10323,"duration_ms":96812,"temperature":0.7,"pith_summary":"This paper tries to establish that a supervised Random Forest detector, trained on execution-time and ciphertext features recorded while AES-128 encryption runs with self-injected anomalies, can outperform a conventional timing-threshold detector in precision and recall while remaining fast enough for embedded, real-time use. The authors build both detectors, generate labels automatically by probabilistically injecting a random delay of 5-20 minutes (timing anomaly) or an XOR of the first plaintext byte with 0xFF (fault anomaly), and evaluate on a CPU and on a PYNQ-Z1 FPGA-based SoC. Their headline result is that the ML detector wins at every injection level, with the largest reported accuracy gain of roughly 49.15% over the threshold method at 80% injection for 1024-block batches. They also report sub-5-millisecond latency on the SoC for block sizes up to 8192 and resource use under 30% of available LUTs and BRAMs, which underpins the real-time feasibility claim. If correct, the framework offers a low-cost way to generate labeled anomaly data and run ML detection inline on lightweight cryptographic hardware.","feed_headline":"Random Forest beats timing threshold on embedded AES","feed_subtitle":"Trained on injected timing and bit-flip faults, it detects anomalies in under 5 ms on a PYNQ-Z1 SoC.","key_machinery":"The core mechanism is the Random Forest classifier, trained on per-block features of encryption time and ciphertext byte values, with ground-truth labels produced automatically by the injection step. Because it can combine a timing feature with content features, the classifier can catch fault-induced changes that leave no timing trace, which is exactly the failure mode of the threshold detector. The threshold detector itself uses a simple statistical rule—mean encryption time plus three times a normalized time range—so it only reacts to latency outliers. The injection procedure (random sleep delays of 5-20 minutes for timing attacks, XOR of the first plaintext byte with 0xFF for fault attacks) does the double duty of creating the labeled training set and fixing what counts as an anomaly, making the whole pipeline self-contained.","core_discovery":"The paper's central claim is that combining timing and ciphertext content features in a Random Forest gives materially better detection of injected timing and fault anomalies than a threshold placed on encryption time alone. In the reported experiments, the Random Forest maintains higher precision and recall across block sizes and injection levels, reduces false positives and false negatives substantially, and at 80% injection with 1024 blocks achieves an accuracy gain of approximately 49.15% over the threshold detector. The same detector, implemented on the PYNQ-Z1, stays under 5 ms latency for block sizes up to 8192 and consumes less than 30% of the FPGA's LUTs and BRAMs, which the authors read as evidence that supervised ML detection is deployable in real time on an embedded SoC. Larger block sizes (8192 and 16384) show steadier performance under high anomaly loads, and parallel cores nearly double throughput at 1024 blocks.","pith_inferences":["A testable extension would be to inject faults inside the AES computation (for example, corrupting a round state rather than the pre-encryption plaintext byte) and rerun the detector; if recall drops, the reported fault-detection power is tied to the injection model rather than to the AES datapath.","The 5-20 minute sleep used to model timing attacks is orders of magnitude larger than the microsecond-scale jitter real timing side channels exploit; adapting the injection to realistic noise magnitudes and cache contention would show how much of the ML gain transfers to genuine side-channel conditions.","Because the threshold statistic is computed from the same batch in which delays were injected, high injection rates contaminate the threshold's baseline; comparing against a threshold trained on clean timing statistics would isolate whether the ML advantage comes from the model or from a weakened baseline."],"forward_implications":["A Random Forest trained on combined timing and ciphertext features should continue to beat a pure timing threshold on the same injected anomaly types at every injection rate, with the largest edge at high anomaly loads.","The same detector can be inserted into an AES encryption pipeline on an FPGA-based SoC with sub-5 ms added latency and under 30% LUT/BRAM overhead, making inline real-time monitoring feasible on lightweight hardware.","Larger block sizes (8192 and 16384) give more stable detection accuracy under high anomaly injection, so batch-style encryption is a more forgiving operating regime for the ML detector.","Because labels are generated automatically during injection, a user can reproduce the labeled dataset for their own AES implementation and retrain the detector without manual annotation."],"supporting_citations":[{"why":"The foundational timing-attack study that establishes why encryption latency is a side-channel signal worth monitoring.","marker":"[11]"},{"why":"The CPU timing-threshold detection scheme that is the direct baseline for the threshold detector and the comparison point for ML gains.","marker":"[13]"},{"why":"The Random Forest anomaly-detection study cited to justify the choice of classifier for the ML detector.","marker":"[7]"},{"why":"The timing-anomaly analysis in cryptographic systems that motivates the random-delay injection model.","marker":"[19]"},{"why":"The AES fault-attack review that supplies the bit-flip fault model used for the injection mechanism.","marker":"[20]"},{"why":"An FPGA fault-mitigation AES design that anchors the comparison on hardware feasibility and resource overhead.","marker":"[12]"}],"fun_headline_variants":["ML-driven AES anomaly detection wins on FPGA in real time","AES fault detection: Random Forest outguns timing checks on SoC","Embedded AES: ML detection trumps threshold in real time","Supervised ML on AES: Random Forest beats threshold on FPGA","AES anomaly detection: ML model outperforms timing watchdog"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the injected anomalies—a random sleep of 5-20 minutes to model timing attacks and an XOR of the first plaintext byte with 0xFF to model fault attacks—faithfully represent the timing jitter and computational faults that real attackers produce; if those simulations are not representative, the reported detection accuracy will not transfer to actual AES deployments.","fun_headline_variants_meta":{"raw":{"variants":["ML-driven AES anomaly detection wins on FPGA in real time","AES fault detection: Random Forest outguns timing checks on SoC","Embedded AES: ML detection trumps threshold in real time","Supervised ML on AES: Random Forest beats threshold on FPGA","AES anomaly detection: ML model outperforms timing watchdog"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000511,"raw_usage":{"total_tokens":2471,"prompt_tokens":915,"completion_tokens":1556,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":531,"completion_tokens_details":{"reasoning_tokens":1470}},"tokens_in":531,"tokens_out":1556,"duration_ms":14305,"temperature":1.0,"reasoning_tokens":1470,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T19:52:47.798301+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Rerun the evaluation with a fault injected into the AES state during encryption (for example, a byte corrupted in round one) instead of an XOR of the first plaintext byte before encryption, and compare the Random Forest's recall against the paper's numbers; a recall drop to the threshold detector's level would show the central claim depends on the injection model rather than on general fault-detection ability.","supporting_citations":[{"cited_title":"Timing attacks on implementations of diffie-hellman, rsa, dss, and other systems,","cited_arxiv_id":null,"evidence_quote":"The foundational timing-attack study that establishes why encryption latency is a side-channel signal worth monitoring."},{"cited_title":"Efficient and low-overhead side-channel attack mitigation using timing thresholding,","cited_arxiv_id":null,"evidence_quote":"The CPU timing-threshold detection scheme that is the direct baseline for the threshold detector and the comparison point for ML gains."},{"cited_title":"Random forest for anomaly detection in cyber- security,","cited_arxiv_id":null,"evidence_quote":"The Random Forest anomaly-detection study cited to justify the choice of classifier for the ML detector."},{"cited_title":"Timing anomaly analysis and detection in crypto- graphic systems,","cited_arxiv_id":null,"evidence_quote":"The timing-anomaly analysis in cryptographic systems that motivates the random-delay injection model."},{"cited_title":"Fault attack and detection techniques for aes encryption: A review,","cited_arxiv_id":null,"evidence_quote":"The AES fault-attack review that supplies the bit-flip fault model used for the injection mechanism."},{"cited_title":"High-throughput and fault-tolerant aes implementation on fpga,","cited_arxiv_id":null,"evidence_quote":"An FPGA fault-mitigation AES design that anchors the comparison on hardware feasibility and resource overhead."}],"review_version":1}