Pith. sign in

REVIEW 3 major objections 6 minor 21 references

ML-Enhanced AES Anomaly Detection for Real-Time Embedded Security

T0 review · 3 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 2507.04197 v1 pith:SSMF2V5V submitted 2025-07-06 cs.CR

Nishant Chinnasami , Rye Stahle-Smith , Rasha Karakchi This is my paper · ORCID
classification cs.CR
keywords AES-128anomalydetectiontimingside-channelfaultinjectionRandomForestembeddedsecurityFPGASoCreal-time
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

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.

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 (3)
  1. [Section III and Algorithm 2 Step 3] 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.
  2. [Section III-A and Table I] 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.
  3. [Table II and Section V-B] 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.
minor comments (6)
  1. [Algorithm 1, line 14] The symbol '¿' appears in the condition 'if encryption time ¿ threshold'; this should be the '>' operator.
  2. [Algorithm 2, line 24] 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.
  3. [Table II caption] 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.
  4. [Section II and References] 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.
  5. [Section V-E] 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.
  6. [Figures 2 and 3] 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.

Circularity Check

1 steps flagged · score 8.0 of 10

ML detector's feature set includes the ground-truth anomaly labels, making the reported detection accuracy a self-definitional copy of the target.

  1. self definitional [Section IV-B (Machine Learning-Based Detection); Algorithm 2, Step 3]
    "We extract features from each encryption block, which include encryption time, byte-level cipher text values and ground truth anomaly labels. A Random Forest classifier is trained on this dataset to distinguish benign from malicious blocks."

    The classifier's target is the anomaly flag, but the feature list includes the ground-truth anomaly labels. A model fed its own target as a feature trivially recovers the label, so the reported precision/recall and the 49.15% gain over threshold measure label copying, not detection from timing/ciphertext. This is output-as-input by construction. Under the paper's own fault model (XOR first plaintext byte with 0xFF before AES), faulty and normal ciphertexts are identically distributed for random plaintexts, so no legitimate byte-level feature can carry fault information; the stated label feature is the only direct route to the reported scores.

full rationale

Section IV-B states that the features include 'ground truth anomaly labels' and the Random Forest is then trained to distinguish benign from malicious blocks; taken literally, the target is an input feature, so the central ML-detection result is circular. The fault-injection model compounds this: since XOR with 0xFF is a bijection and AES is a permutation, C and C' have identical marginal distributions for random plaintexts, so ciphertext-byte features cannot separate fault-injected from normal blocks; timing is normal for fault-only samples. Thus the high recall/F1 values in Table II cannot be produced by legitimate timing/ciphertext features and require the label leakage stated in Section IV-B. The paper does cite the authors' own prior work [9], but that citation only motivates general side-channel risk and is not load-bearing for the detection result, so it does not add circularity. There is no machine-checked or external benchmark that would rehabilitate the label-as-feature statement, and the paper provides no code or cross-validation details that would rule out the literal reading. Verdict: the central prediction claim reduces by construction to the label column; score 8.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

The central claim rests on the realism of the simulated anomalies, the chosen threshold multiplier, the injection ratio sweep, and the unstated Random Forest configuration. None of these are derived from data or from a physical attack model; they are hand-chosen settings that define the benchmark. No new entities are postulated.

free parameters (4)
  • Timing delay range = 5-20 minutes
    Section III states a random sleep between 5 and 20 minutes (or 'short random time' in the algorithms). The magnitude directly determines how separable the timing feature is, and it is inconsistent with the millisecond-scale latencies reported in Table I.
  • Threshold multiplier k = 3
    Section IV-A defines the timing threshold as mean plus 3 times the normalized time range. This multiplier is chosen by hand and directly sets the false positive and false negative tradeoff of the threshold detector.
  • Anomaly injection ratio p = 20% to 80%
    Section V sweeps the injection ratio in 20% increments. Precision, recall, and F1 all depend on this chosen class prior, and the comparison between threshold and ML is only meaningful relative to this prior.
  • Random Forest hyperparameters = not stated
    The number of trees, maximum depth, and split criterion are never reported. These choices affect detection metrics and are free parameters of the evaluation.
assumptions (4)
  • domain assumption Sleeping for a random time before AES encryption simulates a timing side-channel attack.
    Section III and Algorithm 1 use sleep as the timing anomaly, but real timing attacks exploit data-dependent execution paths, not operating-system sleeps. The assumption is load-bearing because the entire timing feature depends on it.
  • domain assumption XORing the first plaintext byte with 0xFF before encryption simulates a fault injection attack.
    Section III treats this as emulating hardware faults, but a plaintext alteration before encryption is an input change, not a transient fault inside the AES datapath. Real fault injection perturbs intermediate computation or state.
  • domain assumption Labels produced by the injection mechanism are valid ground truth for anomaly detection.
    Section V uses injection flags as ground truth, assuming no other sources of anomalies exist and that the simulated anomalies are the target class. This assumption makes the supervised evaluation self-referential.
  • domain assumption AES-128 ECB with a fixed key and random plaintext blocks is representative of real-world AES usage.
    Section III uses random 16-byte blocks in ECB mode. Real workloads have structured plaintext, chaining modes, and varying key schedules, which could change timing and fault profiles.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ML-Enhanced AES Anomaly Detection for Real-Time Embedded Security." pith.science (2026). https://pith.science/paper/SSMF2V5V

@misc{pith2026250704197,
  author       = {Pith},
  title        = {Pith review of: ML-Enhanced AES Anomaly Detection for Real-Time Embedded Security},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SSMF2V5V}},
  note         = {Machine review of arXiv:2507.04197}
}
read the original abstract

Advanced Encryption Standard (AES) is a widely adopted cryptographic algorithm, yet its practical implementations remain susceptible to side-channel and fault injection attacks. In this work, we propose a comprehensive framework that enhances AES-128 encryption security through controlled anomaly injection and real-time anomaly detection using both statistical and machine learning (ML) methods. We simulate timing and fault-based anomalies by injecting execution delays and ciphertext perturbations during encryption, generating labeled datasets for detection model training. Two complementary detection mechanisms are developed: a threshold-based timing anomaly detector and a supervised Random Forest classifier trained on combined timing and ciphertext features. We implement and evaluate the framework on both CPU and FPGA-based SoC hardware (PYNQ-Z1), measuring performance across varying block sizes, injection rates, and core counts. Our results show that ML-based detection significantly outperforms threshold-based methods in precision and recall while maintaining real-time performance on embedded hardware. Compared to existing AES anomaly detection methods, our solution offers a low-cost, real-time, and accurate detection approach deployable on lightweight FPGA platforms.

Figures

Figures reproduced from arXiv: 2507.04197 by the authors.

Figure 1
Figure 1. Proposed threshold-based and ML-based framework. [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Accuracy gain of ML-based detector over threshold detection. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. False Positives (FP) and False Negatives (FN) comparison for [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

21 extracted references · 20 canonical work pages

  1. [1]

    Cryptography and security techniques for iot devices: A comprehensive survey,

    A. Singh, P. K. Sharma, and J. J. Rodrigues, “Cryptography and security techniques for iot devices: A comprehensive survey,” IEEE Communications Surveys & Tutorials , vol. 21, no. 1, pp. 121–144, 2019

    work page 2019

  2. [2]

    A comprehensive survey on fault attacks and countermea- sures for cryptographic devices,

    Y . Li et al. , “A comprehensive survey on fault attacks and countermea- sures for cryptographic devices,”IEEE Access, vol. 7, pp. 86 827–86 850, 2019

    work page 2019

  3. [3]

    Fault injection attacks on aes: A review,

    M. A. Hasan, M. H. Kabir, and M. M. Hasan, “Fault injection attacks on aes: A review,” Information Security Journal , vol. 30, no. 2, pp. 67–79, 2021

    work page 2021

  4. [4]

    Side-channel attack detection techniques: A survey,

    J. Kim, S. Lee, and D. Hong, “Side-channel attack detection techniques: A survey,” ACM Computing Surveys , vol. 53, no. 3, 2020

    work page 2020

  5. [5]

    Machine learning in cyber-physical systems: Se- curity, privacy, and trust,

    W. Wang and Y . Xu, “Machine learning in cyber-physical systems: Se- curity, privacy, and trust,” IEEE Transactions on Industrial Informatics , vol. 17, no. 10, pp. 6792–6803, 2021

    work page 2021

  6. [6]

    Ml-based side-channel analysis and coun- termeasures: A review,

    S. Yu, Q. Xu, and Z. Lin, “Ml-based side-channel analysis and coun- termeasures: A review,” IEEE Transactions on Dependable and Secure Computing, 2023

    work page 2023

  7. [7]

    Random forest for anomaly detection in cyber- security,

    F. Zhang and W. He, “Random forest for anomaly detection in cyber- security,” IEEE Access , vol. 8, pp. 55 323–55 335, 2020

    work page 2020

  8. [8]

    Pynq-z1: Python productivity for zynq-7000 arm/fpga soc,

    D. Inc., “Pynq-z1: Python productivity for zynq-7000 arm/fpga soc,” https://digilent.com/shop/ pynq-z1-python-productivity-for-zynq-7000-arm-fpga-soc/, 2025, accessed: 2025-06-16. [Online]. Available: https://digilent.com/shop/ pynq-z1-python-productivity-for-zynq-7000-arm-fpga-soc/

    work page 2025

Show all 21 references
  1. [9]

    Toward a lightweight, scalable, and parallel secure encryption engine,

    R. Karakchi, R. Stahle-Smith, N. Chinnasami, and T. Yu, “Toward a lightweight, scalable, and parallel secure encryption engine,” arXiv preprint arXiv:2506.15070, 2025

    2025 arXiv

  2. [10]

    Hardware fault injection attacks on embedded cryptosystems: A review,

    M. S. Islam et al. , “Hardware fault injection attacks on embedded cryptosystems: A review,” IEEE Transactions on Circuits and Systems I, vol. 69, no. 1, pp. 67–79, 2022

    2022

  3. [11]

    Timing attacks on implementations of diffie-hellman, rsa, dss, and other systems,

    P. C. Kocher, “Timing attacks on implementations of diffie-hellman, rsa, dss, and other systems,” in CRYPTO, 1996

    1996

  4. [12]

    High-throughput and fault-tolerant aes implementation on fpga,

    M. Alawieh and A. Raghunathan, “High-throughput and fault-tolerant aes implementation on fpga,” in 2018 IEEE International Symposium on Hardware Oriented Security and Trust (HOST) . IEEE, 2018, pp. 69–74

    2018

  5. [13]

    Efficient and low-overhead side-channel attack mitigation using timing thresholding,

    H. Liu and C. Wu, “Efficient and low-overhead side-channel attack mitigation using timing thresholding,” IEEE Transactions on Computers, vol. 70, no. 2, pp. 230–244, 2021

    2021

  6. [14]

    Hardware implementation of aes with fault detection,

    S. A. Purnaprajna and B. S. Shylaja, “Hardware implementation of aes with fault detection,” in 2015 International Conference on VLSI Systems, Architecture, Technology and Applications (VLSI-SATA) . IEEE, 2015, pp. 1–6

    2015

  7. [15]

    Sherlock: Unsupervised fault detection in embedded systems using lightweight profiling,

    M. Hong, S. Lee, and Y . Kim, “Sherlock: Unsupervised fault detection in embedded systems using lightweight profiling,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , 2023

    2023

  8. [16]

    An fpga-based online learning system for anomaly detection in iot networks,

    S. Khan, M. Arif, and Others, “An fpga-based online learning system for anomaly detection in iot networks,” in 2022 International Conference on ReConFigurable Computing and FPGAs (ReConFig) . IEEE, 2022, pp. 99–104

    2022

  9. [17]

    Advanced encryption standard (aes),

    “Advanced encryption standard (aes),” NIST, Tech. Rep. FIPS PUB 197, 2001

    2001

  10. [18]

    What is a timing attack?

    G. Wright, “What is a timing attack?” 2023, accessed: 2025- 06-16. [Online]. Available: https://www.techtarget.com/searchsecurity/ definition/timing-attack

    2023

  11. [19]

    Timing anomaly analysis and detection in crypto- graphic systems,

    C. Jin and M. Tan, “Timing anomaly analysis and detection in crypto- graphic systems,” IEEE Transactions on Computers , vol. 69, no. 11, pp. 1663–1676, 2020

    2020

  12. [20]

    Fault attack and detection techniques for aes encryption: A review,

    Y . Liu et al. , “Fault attack and detection techniques for aes encryption: A review,” Microprocessors and Microsystems , vol. 81, 2021

    2021

  13. [21]

    Idiot’s bayes—not so stupid after all?

    D. J. Hand and K. Yu, “Idiot’s bayes—not so stupid after all?” International Statistical Review , vol. 69, no. 3, pp. 385–398, 2001

    2001

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.