pith. sign in

arxiv: 2606.19807 · v1 · pith:4S3ZFH7Knew · submitted 2026-06-18 · 💻 cs.CR

DISARM: Target Electronic Device Informed Mitigation of Software Runtime Side-Channel Vulnerabilities

Tasneem Suha , Tanzim Mahfuz , Rima Asmar Awad , Prabuddha Chakraborty This is my paper

Pith reviewed 2026-06-26 17:17 UTC · model grok-4.3

classification 💻 cs.CR
keywords runtime side-channeltiming attacksembedded device mitigationhardware-software co-designexecution time balancingsoftware security patchingedge device vulnerabilities
0
0 comments X

The pith

DISARM collects timing measurements from the actual target device to generate software fixes that balance execution paths and reduce timing leaks more accurately than hardware-blind methods.

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

The paper introduces a joint hardware-software process that first runs the program on the real embedded device to capture actual timing values for different control-flow paths, then feeds those values into an automated generator that inserts only the operations needed to equalize times. This targets the common failure modes of prior balancing techniques that either add unnecessary code or leave detectable imbalances because they assume uniform hardware behavior. A reader would care because many security-sensitive programs run on constrained edge devices where timing attacks can extract keys or other secrets, and an approach that respects the specific hardware could cut both performance cost and residual leakage. The work validates the process on 22 benchmarks in C, C++, and Java across five devices and reports lower execution-time overhead, smaller code-size growth, and fewer correctness failures than PENDULUM and DifFuzzAR.

Core claim

DISARM measures execution times directly on the intended embedded or edge device and uses those device-specific values to drive an automated software patch generator that equalizes timing across sensitive control-flow paths, thereby mitigating runtime side-channel leakage while avoiding the over-fixing and under-fixing that occur when mitigation ignores the underlying hardware.

What carries the argument

The device-informed fix generator that ingests real timing traces from the target hardware to produce minimal, path-specific code changes that equalize execution latency.

If this is right

  • Fixes generated for one device will not transfer directly to another device without re-collecting timing data.
  • The same measurement-plus-generator loop can be applied to any C, C++, or Java program that contains timing-sensitive control flow.
  • Overhead stays below that of PENDULUM and DifFuzzAR on the tested embedded platforms while achieving higher leakage elimination rates.
  • Code-size growth remains modest because only the minimal balancing operations suggested by the device's own measurements are inserted.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same device-trace approach could be applied to other observable side channels such as power or electromagnetic emissions if the corresponding sensors are added to the measurement step.
  • Automated generation of device-specific patches may reduce the expertise barrier for securing legacy embedded code that cannot be rewritten from scratch.
  • If the measurement step is made periodic, the method could support runtime adaptation when firmware or hardware revisions alter timing behavior.

Load-bearing premise

That timing traces collected once from the target device are sufficient to produce fixes that eliminate leakage without creating new timing variations or requiring per-device manual adjustments.

What would settle it

Running a standard timing-attack tool on a program after DISARM patching and observing either remaining statistically significant timing differences or an increase in attack success rate compared with the original code.

Figures

Figures reproduced from arXiv: 2606.19807 by Prabuddha Chakraborty, Rima Asmar Awad, Tanzim Mahfuz, Tasneem Suha.

Figure 1
Figure 1. Figure 1: Threat Model: Strength of the attacker depends on [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of DISARM : Hardware-in-the-loop and specific threat model tailored mitigation of software timing vulnerabilities. device and hence the execution time measurement may be less accurate [21]. Hence, a timing side-channel mitigation framework must consider software, hardware, and also precise threat model to generate efficient and effective solutions. However, most state-of-the-art (e.g., DifFuzzAR [… view at source ↗
Figure 3
Figure 3. Figure 3: Branch on Secret (BoS) vulnerability. LoS Resilience = min n∈N  n|n × ∆t ≥ T  (6) Here, ∆t is the per iteration time difference derived from the hardware-level basic block timings in the control flow graph. n is the number of loop iterations controlled by the secret. In other words, the loop must run at least LoS Resilience times before the attacker can reliably discern a timing difference attributable t… view at source ↗
Figure 4
Figure 4. Figure 4: Loop on Secret (LoS) vulnerability. By building a verified, sound type checker, authors even supply a compiler pass to rewrite existing crypto libraries into CT￾Wasm; for example, a TweetNaCl implementation compiled under CT-Wasm is shown to run in equal time for all inputs. This formal approach is powerful because it provides provable guarantees of no timing leakage. Potential limitations are: it applies … view at source ↗
Figure 5
Figure 5. Figure 5: BoS Severity after fixing the code-base with DISARM (Baseline model) for timing sensitivity T = 5 [PITH_FULL_IMAGE:figures/full_fig_p011_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: BoS Severity after fixing the code-base with DISARM (Baseline model) for timing sensitivity T = 10. can say that our framework outperforms the SOTA techniques. VI. RESULTS: C++/C BENCHMARKS We evaluate DISARM on five real-world embedded devices to focus on several hardware architectures as outlined in Table III and utilizing the same CPU-cycle measurement tech￾niques as specified for the Java benchmarks (s… view at source ↗
Figure 7
Figure 7. Figure 7: LoS Severity after DISARM for timing sensitivity 50 and minimum LoS Resilience is 10 with variable timing effect. threat model inspired by HASTE [27], for ‘weak attack’ we choose timing sensitivity (T ) = 10 for BoS severity and minimum LoS resilience (Lmin) = 5 for LoS severity, on the other hand for ‘stronger attack’ we choose timing sensitivity (T ) = 5 for BoS severity and minimum LoS resilience (Lmin)… view at source ↗
Figure 8
Figure 8. Figure 8: LoS Severity after DISARM for timing sensitivity 50 and minimum LoS Resilience is 5 with variable timing effect. fresh seed. This step is carried out for each run to calculate the average basic block runtime (NRun = 100, in Algorithm 1). A. Mitigating BoS Vulnerabilities Algorithm 3 mitigates the BoS vulnerability in RSA modular exponentiation by synthesizing hardware-in-the-loop patched subroutines (Table… view at source ↗
Figure 9
Figure 9. Figure 9: BoS severity (before and after applying DISARM) for Traces (NT ) = 10 and Timing sensitivity T = 5 [PITH_FULL_IMAGE:figures/full_fig_p014_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: BoS severity (before and after applying DISARM) for Traces (NT ) = 100 and Timing sensitivity T = 5. 2) Considering the Effect of Branch Prediction: The left half of the Table VI reports LoS severity for the original [PITH_FULL_IMAGE:figures/full_fig_p014_10.png] view at source ↗
read the original abstract

Program runtime or timing attacks exploit variations in a program's execution times to extract sensitive information from the program (e.g. encryption keys, sensitive variable data, intellectual property). State-of-the-art solutions to runtime side-channel attacks attempt to balance the execution time of the sensitive code for different control flow paths to eliminate the timing leakage. However, during the mitigation process, most techniques do not consider the underlying hardware or device on which the target program is supposed to run on. This can lead to over-fixing (unnecessary extra operations), under-fixing (not solving the imbalance properly), and even failures. We propose DISARM, a joint hardware-software methodology (unlike any existing solution) for mitigating runtime side-channel vulnerabilities that utilizes timing values from real embedded devices to generate targeted software fixes. We implement DISARM to support C, C++, and Java source codes and validate it across 22 standard benchmarks. DISARM outperforms state-of-the-art solutions such as PENDULUM and DifFuzzAR in terms of execution time overhead, code size overhead, and correctness on five different embedded or edge devices.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The manuscript proposes DISARM, a joint hardware-software methodology for mitigating runtime side-channel vulnerabilities. It collects timing values from the target embedded device to generate targeted software fixes that balance execution times across control-flow paths in C, C++, and Java programs. The approach is validated across 22 standard benchmarks and claimed to outperform PENDULUM and DifFuzzAR in execution time overhead, code size overhead, and correctness on five embedded or edge devices.

Significance. If the central claims hold with proper validation, the work would be significant for embedded and edge-device security by addressing over-fixing and under-fixing through device-informed timing data rather than generic balancing. Multi-language support and evaluation across multiple devices are strengths. However, the absence of quantified correctness metrics limits its immediate contribution to the field.

major comments (2)
  1. [Abstract] Abstract: The claim of outperformance on correctness across 22 benchmarks and five devices is stated without any description of the methodology for measuring correctness (e.g., attack success rate, statistical tests on timing variance, or mutual information), data collection protocol, or error bars. This directly undermines verification of the central claim that device-specific timing produces reliable fixes without over- or under-fixing.
  2. [Evaluation section] Evaluation section: The core assumption that feeding real-device timing values into the fix generator eliminates leakage without introducing new side channels or requiring manual per-device tuning is not supported by explicit leakage tests or cross-input validation results. Timing noise and device dependence make this load-bearing for the joint hardware-software contribution, yet no such tests are reported.
minor comments (1)
  1. [Abstract] Abstract: The phrase 'on which the target program is supposed to run on' is grammatically redundant.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. We address each major comment below and will revise the manuscript to improve clarity on correctness metrics and validation.

read point-by-point responses

  1. Referee: [Abstract] Abstract: The claim of outperformance on correctness across 22 benchmarks and five devices is stated without any description of the methodology for measuring correctness (e.g., attack success rate, statistical tests on timing variance, or mutual information), data collection protocol, or error bars. This directly undermines verification of the central claim that device-specific timing produces reliable fixes without over- or under-fixing.

    Authors: We agree the abstract should summarize the correctness methodology. In the manuscript, correctness is quantified by measuring the reduction in execution-time variance across control-flow paths using repeated real-device timing samples (1000+ runs per benchmark per device), confirming post-mitigation variance falls below an attack threshold derived from baseline leakage, with no new leaks introduced (verified via cross-path timing equality). Data collection uses the target device's cycle-accurate timer under controlled inputs. We will revise the abstract to include this description, reference to error bars from multiple runs, and the protocol, enabling verification of the device-informed claim. revision: yes

  2. Referee: [Evaluation section] Evaluation section: The core assumption that feeding real-device timing values into the fix generator eliminates leakage without introducing new side channels or requiring manual per-device tuning is not supported by explicit leakage tests or cross-input validation results. Timing noise and device dependence make this load-bearing for the joint hardware-software contribution, yet no such tests are reported.

    Authors: The evaluation reports empirical results across five devices and 22 benchmarks showing lower overhead and higher correctness than PENDULUM and DifFuzzAR, which supports the assumption via device-specific balancing. However, we acknowledge the absence of explicit cross-input leakage tests (e.g., attack success rates or mutual information) and additional validation for new side channels. We will add a dedicated subsection with these tests, including statistical analysis of timing distributions pre/post-mitigation and cross-input checks, to directly substantiate the joint hardware-software contribution. revision: yes

Circularity Check

0 steps flagged

No circularity detected in derivation chain

full rationale

The paper describes an empirical methodology that collects timing measurements from target embedded devices and uses them to generate software fixes for side-channel vulnerabilities. No equations, parameter-fitting steps, self-citations, or uniqueness theorems are referenced in the provided text. The central claims rest on external real-device validation across 22 benchmarks and 5 devices rather than any internal redefinition or self-referential construction. The approach is therefore self-contained against external benchmarks with no load-bearing step that reduces to its own inputs by definition.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Abstract-only review supplies no information on free parameters, axioms, or invented entities used by the method.

pith-pipeline@v0.9.1-grok · 5736 in / 1093 out tokens · 28781 ms · 2026-06-26T17:17:46.563651+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

51 extracted references · 3 canonical work pages · 1 internal anchor

  1. [1]

    Current research on internet of things (iot) security: A survey,

    W. H. Hassanet al., “Current research on internet of things (iot) security: A survey,”Computer networks, vol. 148, pp. 283–294, 2019

    2019

  2. [2]

    Side-channel attack in internet of things: A survey,

    M. Devi and A. Majumder, “Side-channel attack in internet of things: A survey,” inApplications of Internet of Things: Proceedings of ICCCIOT

  3. [3]

    Springer, 2021, pp. 213–222

    2021

  4. [4]

    Side-channel attacks in the internet of things: threats and challenges,

    A. Zankl, H. Seuschek, G. Irazoqui, and B. Gulmezoglu, “Side-channel attacks in the internet of things: threats and challenges,” inResearch Anthology on Artificial Intelligence Applications in Security. IGI Global, 2021, pp. 2058–2090

    2021

  5. [5]

    Consumer iot: Security vulnerability case studies and solutions,

    T. Alladi, V . Chamola, B. Sikdar, and K.-K. R. Choo, “Consumer iot: Security vulnerability case studies and solutions,”IEEE Consumer Electronics Magazine, vol. 9, no. 2, pp. 17–25, 2020

    2020

  6. [6]

    Iot security, privacy, safety and ethics,

    H. F. Atlam and G. B. Wills, “Iot security, privacy, safety and ethics,” Digital twin technologies and smart cities, pp. 123–149, 2020

    2020

  7. [7]

    Introduction to side-channel attacks,

    F.-X. Standaert, “Introduction to side-channel attacks,”Secure integrated circuits and systems, pp. 27–42, 2010

    2010

  8. [8]

    Systematic classification of side-channel attacks: A case study for mobile devices,

    R. Spreitzer, V . Moonsamy, T. Korak, and S. Mangard, “Systematic classification of side-channel attacks: A case study for mobile devices,” IEEE communications surveys & tutorials, vol. 20, no. 1, pp. 465–488, 2017

    2017

  9. [9]

    Side-channel attacks: Ten years after its pub- lication and the impacts on cryptographic module security testing,

    Y . Zhou and D. Feng, “Side-channel attacks: Ten years after its pub- lication and the impacts on cryptographic module security testing,” Cryptology ePrint Archive, 2005

    2005

  10. [10]

    An information-theoretic model for adaptive side-channel attacks,

    B. K ¨opf and D. Basin, “An information-theoretic model for adaptive side-channel attacks,” inProceedings of the 14th ACM conference on Computer and communications security, 2007, pp. 286–296

    2007

  11. [11]

    A survey of side-channel attacks on caches and countermeasures,

    Y . Lyu and P. Mishra, “A survey of side-channel attacks on caches and countermeasures,”Journal of Hardware and Systems Security, vol. 2, pp. 33–50, 2018

    2018

  12. [12]

    Timing side-channel attacks and countermeasures in cpu microarchitectures,

    J. Zhang, C. Chen, J. Cui, and K. Li, “Timing side-channel attacks and countermeasures in cpu microarchitectures,”ACM Computing Surveys, vol. 56, no. 7, pp. 1–40, 2024

    2024

  13. [13]

    A refined look at bernstein’s aes side-channel analysis,

    M. Neve, J.-P. Seifert, and Z. Wang, “A refined look at bernstein’s aes side-channel analysis,” inProceedings of the 2006 ACM Symposium on Information, computer and communications security, 2006, pp. 369–369

    2006

  14. [14]

    Low-cost solutions for preventing simple side-channel analysis: Side-channel atomicity,

    B. Chevallier-Mames, M. Ciet, and M. Joye, “Low-cost solutions for preventing simple side-channel analysis: Side-channel atomicity,”IEEE Transactions on computers, vol. 53, no. 6, pp. 760–768, 2004

    2004

  15. [15]

    Improved techniques for side-channel analysis,

    P. Rohatgi, “Improved techniques for side-channel analysis,”Crypto- graphic Engineering, pp. 381–406, 2009

    2009

  16. [16]

    Hardware side-channel

    “Hardware side-channel.” [Online]. Available: https://niemierlab.nd.edu/ research/thread-03-hardware-security-side-channels/

  17. [17]

    Chronos: Timing interference as a new attack vector on autonomous cyber-physical systems,

    A. Li, J. Wang, and N. Zhang, “Chronos: Timing interference as a new attack vector on autonomous cyber-physical systems,” inProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021, pp. 2426–2428

    2021

  18. [18]

    Opportunities and limits of remote timing attacks,

    S. A. Crosby, D. S. Wallach, and R. H. Riedi, “Opportunities and limits of remote timing attacks,”ACM Transactions on Information and System Security (TISSEC), vol. 12, no. 3, pp. 1–29, 2009

    2009

  19. [19]

    Remote timing attacks are still practical,

    B. B. Brumley and N. Tuveri, “Remote timing attacks are still practical,” inEuropean Symposium on Research in Computer Security. Springer, 2011, pp. 355–371

    2011

  20. [20]

    Attacks on physical-layer identification,

    B. Danev, H. Luecken, S. Capkun, and K. El Defrawy, “Attacks on physical-layer identification,” inProceedings of the third ACM confer- ence on Wireless network security, 2010, pp. 89–98

    2010

  21. [21]

    A cache timing attack on aes in virtualization environments,

    M. Weiß, B. Heinz, and F. Stumpf, “A cache timing attack on aes in virtualization environments,” inFinancial Cryptography and Data Security: 16th International Conference, FC 2012, Kralendijk, Bonaire, Februray 27-March 2, 2012, Revised Selected Papers 16. Springer, 2012, pp. 314–328

    2012

  22. [22]

    Remote timing attacks are practical,

    D. Brumley and D. Boneh, “Remote timing attacks are practical,” Computer Networks, vol. 48, no. 5, pp. 701–716, 2005

    2005

  23. [23]

    Diffuzzar: automatic repair of timing side-channel vulnerabilities via refactoring,

    R. Lima, J. F. Ferreira, A. Mendes, and C. Carreira, “Diffuzzar: automatic repair of timing side-channel vulnerabilities via refactoring,” Automated Software Engineering, vol. 31, no. 1, p. 1, 2024

    2024

  24. [24]

    Timing side-channel mitigation via automated program repair,

    H. Ruan, Y . Noller, S. Tizpaz-Niari, S. Chattopadhyay, and A. Roychoudhury, “Timing side-channel mitigation via automated program repair,”ACM Trans. Softw. Eng. Methodol., Jul. 2024, just Accepted. [Online]. Available: https://doi.org/10.1145/3678169

    work page doi:10.1145/3678169 2024

  25. [25]

    Ct-wasm: type-driven secure cryptography for the web ecosystem,

    C. Watt, J. Renner, N. Popescu, S. Cauligi, and D. Stefan, “Ct-wasm: type-driven secure cryptography for the web ecosystem,”Proceedings of the ACM on Programming Languages, vol. 3, no. POPL, pp. 1–29, 2019

    2019

  26. [26]

    ct-fuzz: Fuzzing for timing leaks,

    S. He, M. Emmi, and G. Ciocarlie, “ct-fuzz: Fuzzing for timing leaks,” in2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST). IEEE, 2020, pp. 466–471

    2020

  27. [27]

    Timeless timing attacks: Exploiting concurrency to leak secrets over remote con- nections,

    T. Van Goethem, C. P ¨opper, W. Joosen, and M. Vanhoef, “Timeless timing attacks: Exploiting concurrency to leak secrets over remote con- nections,” inProceedings of the 29th USENIX Conference on Security Symposium, 2020, pp. 1985–2002

    2020

  28. [28]

    Haste: Soft- ware security analysis for timing attacks on clear hardware assumption,

    P. Chakraborty, J. Cruz, C. Posada, S. Ray, and S. Bhunia, “Haste: Soft- ware security analysis for timing attacks on clear hardware assumption,” IEEE Embedded Systems Letters, vol. 14, no. 2, pp. 71–74, 2021

    2021

  29. [29]

    Boom core

    “Boom core.” [Online]. Available: https://boom-core.org/

  30. [30]

    Dude, is my code constant time?

    O. Reparaz, J. Balasch, and I. Verbauwhede, “Dude, is my code constant time?” inDesign, Automation & Test in Europe Conference & Exhibition (DATE), 2017. IEEE, 2017, pp. 1697–1702

    2017

  31. [31]

    Sparse representation of implicit flows with applications to side-channel detec- tion,

    B. Rodrigues, F. M. Quint ˜ao Pereira, and D. F. Aranha, “Sparse representation of implicit flows with applications to side-channel detec- tion,” inProceedings of the 25th International Conference on Compiler Construction, 2016, pp. 110–120

    2016

  32. [32]

    Nemesisguard: Mitigating interrupt latency side channel attacks with static binary rewriting,

    M. Salehi, G. De Borger, D. Hughes, and B. Crispo, “Nemesisguard: Mitigating interrupt latency side channel attacks with static binary rewriting,”Computer Networks, vol. 205, p. 108744, 2022

    2022

  33. [33]

    Diffuzz: differential fuzzing for side-channel analysis,

    S. Nilizadeh, Y . Noller, and C. S. Pasareanu, “Diffuzz: differential fuzzing for side-channel analysis,” in2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 176–187

    2019

  34. [34]

    Hardware support for constant-time programming,

    Y . Miao, M. T. Kandemir, D. Zhang, Y . Zhang, G. Tan, and D. Wu, “Hardware support for constant-time programming,” in Proceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture, ser. MICRO ’23. New York, NY , USA: Association for Computing Machinery, 2023, p. 856–870. [Online]. Available: https://doi.org/10.1145/3613424.3623796

    work page doi:10.1145/3613424.3623796 2023

  35. [35]

    Secure compilation of side- channel countermeasures: the case of cryptographic “constant-time

    G. Barthe, B. Gr ´egoire, and V . Laporte, “Secure compilation of side- channel countermeasures: the case of cryptographic “constant-time”,” in2018 IEEE 31st Computer Security Foundations Symposium (CSF). IEEE, 2018, pp. 328–343

    2018

  36. [36]

    Research and implementation of rsa algorithm for encryption and decryption,

    X. Zhou and X. Tang, “Research and implementation of rsa algorithm for encryption and decryption,” inProceedings of 2011 6th International Forum on Strategic Technology, vol. 2, 2011, pp. 1118–1121

    2011

  37. [37]

    Searching for Activation Functions

    P. Ramachandran, B. Zoph, and Q. V . Le, “Searching for activation functions,”arXiv preprint arXiv:1710.05941, 2017

    work page internal anchor Pith review Pith/arXiv arXiv 2017

  38. [38]

    Leaky relu activation function

    “Leaky relu activation function.” [Online]. Avail- able: https://machinelearningmastery.com/rectified-linear-activation- function-for-deep-learning-neural-networks/

  39. [39]

    Sigmoid activation function

    “Sigmoid activation function.” [Online]. Available: https://builtin.com/ machine-learning/sigmoid-activation-function

  40. [40]

    Data compression using run length encoding

    “Data compression using run length encoding.” [Online]. Available: https://www.sciencedirect.com/topics/computer-science/run- length-encoding

  41. [41]

    Convolution layer

    “Convolution layer.” [Online]. Available: https://www.sciencedirect. com/topics/engineering/convolutional-layer

  42. [42]

    A public key cryptosystem and a signature scheme based on discrete logarithms,

    T. ElGamal, “A public key cryptosystem and a signature scheme based on discrete logarithms,”IEEE transactions on information theory, vol. 31, no. 4, pp. 469–472, 1985

    1985

  43. [43]

    New directions in cryptography,

    W. Diffie and M. E. Hellman, “New directions in cryptography,” in Democratizing Cryptography: The Work of Whitfield Diffie and Martin Hellman, 2022, pp. 365–390

    2022

  44. [44]

    Cryptography and computer privacy,

    H. Feistel, “Cryptography and computer privacy,”Scientific american, vol. 228, no. 5, pp. 15–23, 1973

    1973

  45. [45]

    Schneier,Applied cryptography: protocols, algorithms, and source code in C

    B. Schneier,Applied cryptography: protocols, algorithms, and source code in C. john wiley & sons, 2007

    2007

  46. [46]

    Cryptography in an algebraic alphabet,

    L. S. Hill, “Cryptography in an algebraic alphabet,”The American Mathematical Monthly, vol. 36, no. 6, pp. 306–312, 1929

    1929

  47. [47]

    Paul and S

    G. Paul and S. Maitra,RC4 stream cipher and its variants. CRC press, 2011

    2011

  48. [48]

    Pendulum source code,

    PENDULUM, “Pendulum source code,” accessed: 2025-02-02. [Online]. Available: https://figshare.com/s/8f13e48bc98727ae8754?file=47440988

    2025

  49. [49]

    Performance counter

    “Performance counter.” [Online]. Available: https://perfwiki.github.io/ main/

  50. [50]

    Thinlto: scalable and incremental lto,

    T. Johnson, M. Amini, and X. D. Li, “Thinlto: scalable and incremental lto,” in2017 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). IEEE, 2017, pp. 111–121

    2017

  51. [51]

    Hornet: An efficient data structure for dynamic sparse graphs and matrices on gpus,

    F. Busato, O. Green, N. Bombieri, and D. A. Bader, “Hornet: An efficient data structure for dynamic sparse graphs and matrices on gpus,” in 2018 IEEE High Performance extreme Computing Conference (HPEC). IEEE, 2018, pp. 1–7

    2018