Pith. sign in

REVIEW 3 major objections 5 minor 37 references

Vogls: a Fast Interactive Full-timing Simulator for Pre-silicon Power Side-Channel Analysis

T0 review · 3 major / 5 minor · reviewed 2026-08-01 · deepseek-v4-flash

Pith's one-line read Vogls is a Verilog simulator that combines compiled-code speed, full-timing semantics, and forkable simulation state for pre-silicon side-channel analysis.

desk verdict Vogls is a practical tool paper with a real contribution, but the full-timing fidelity claim needs differential testing and the artifact must be released. read the letter →

arxiv 2607.15782 v1 pith:LAGGLLN6 submitted 2026-07-17 cs.CR cs.AR

classification cs.CRcs.AR
keywords pre-siliconside-channelanalysisfull-timingsimulationVerilogsimulatorstateforkingdifferentialpowergate-leveltimingVoglsIntermediateRepresentationtracecollection
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

The paper argues that pre-silicon power side-channel analysis needs a simulator that is fast enough to collect thousands of traces, accurate enough to model gate-level timing including glitches and delays, and controllable enough to fork, mutate, and resume around a point of interest. It presents Vogls, which compiles Verilog designs to C, supports full-timing semantics via specify blocks and SDF annotations, and separates design from state so that a simulation can be copied inexpensively. In benchmarks, Vogls simulates a timing-annotated gate-level AES design 5.9 times faster than the open-source reference simulator Icarus Verilog and runs a PicoRV32 RTL design only 30% slower than Verilator. A case study demonstrates a differential power analysis attack recovering an AES key at RTL, gate-level, and full-timing gate-level abstractions. The pith is that combining these three properties removes a practical barrier: timing-accurate side-channel evaluation no longer forces analysts to restart from reset for every trace.

What carries the argument

The load-bearing mechanism is the Vogls Intermediate Representation (VIR), a temporally-aware SSA/control-flow-graph representation that keeps Verilog's scheduling semantics explicit. VIR lowers to either a bytecode interpreter or generated C code, which the host compiler turns into native code. Around VIR, the design is separated from the mutable simulation state (time, signal values, listeners, update times); forking copies only the state. Timing annotations such as specify blocks and SDF delays are compiled into VIR processes using 'last update time' instructions and timed waits, which is how full-timing glitch behavior is preserved. This combination lets Vogls re-run only a short window

What would settle it

Take a timing-annotated gate-level netlist, simulate the same input vector in Vogls and in a mature full-timing reference simulator (or measure a fabricated FPGA/ASIC implementation), and compare per-transition signal activity and glitch behavior at each timestamp. A divergence in glitch count or transition timing in Vogls relative to the reference would invalidate the claim that Vogls preserves full-timing leakage characteristics and would make the reported minimum-trace-to-disclosure numbers an artifact of Vogls' model rather than a property of the design.

Watch

Extended reading notes

Core claim

The central claim is that a simulator purpose-built for side-channel analysis can simultaneously deliver compiled-code performance, full-timing (sub-cycle) simulation, and fine-grained control over simulation state, and that this combination changes what is practical in pre-silicon SCA. Vogls achieves this by compiling the design to C while retaining a temporally-aware intermediate representation (VIR) that models Verilog scheduling, specify blocks, and SDF timing annotations. State is separated from design, so a simulation can be forked after expensive setup logic and reused across many traces with mutated inputs, preserving the design's timing and leakage characteristics. The paper reports

Load-bearing premise

The load-bearing premise is that Vogls correctly implements IEEE Verilog full-timing delay scheduling (specify blocks and SDF); the paper reports no differential testing against a reference simulator or against hardware to verify this.

Editorial extensions

If this is right

  • Full-timing gate-level SCA trace collection becomes practical on designs previously too slow to simulate; the paper captures 30,000 full-timing traces in about 100 seconds using 8 worker threads.
  • The same DPA workflow runs across RTL, GTL, and full-timing GTL abstraction levels without redesign, enabling direct cross-abstraction leakage comparisons on one design.
  • Adaptive and online side-channel attacks, which need to inspect and mutate simulation state mid-run, are directly supported through the Python interface.
  • VIR provides a unified intermediate representation that could be reused by other tools needing temporal semantics, such as formal timing-property verification or independent pre-silicon SCA analyzers.
  • Because the design is never modified, forking preserves the timing and leakage characteristics of the original circuit for each reused trace.

Reading between the lines

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

  • If Vogls' full-timing semantics prove faithful to real hardware, pre-silicon leakage assessment could routinely catch glitch-based leakages that cycle-accurate simulation misses, shifting countermeasure evaluation toward full-timing by default.
  • The state-forking model implies a natural parallelization strategy: independent state copies need no synchronization, so trace generation can scale across cores or distributed systems without the usual overhead.
  • The 30% performance gap to Verilator is measured on RTL; with the VIR optimizations the paper proposes, compiled Vogls may close much of that gap while retaining full-timing fidelity, making it viable for functional verification as well.
  • A key unresolved question is whether Vogls' timing-accurate glitch behavior on a specific cell library correlates with physical measurements; if it does, Vogls could become a low-cost substitute for FPGA-based leakage assessment in early design iterations.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper presents Vogls, a new open-source Verilog simulator aimed at pre-silicon power side-channel analysis. Vogls compiles Verilog designs to a custom intermediate representation (VIR) and then to either bytecode or native C code. Its main claimed contributions are (1) full-timing simulation performance superior to Icarus Verilog and comparable to Verilator on an RTL design, (2) a Python interface that supports forking, inspecting, and mutating simulation state without modifying the design, and (3) a case study showing a DPA attack recovering an AES key at RTL, GTL, and full-timing GTL abstraction levels. The performance numbers in Table II largely recompute as stated, and the case study in Table III demonstrates the workflow. However, the paper's central full-timing claim rests on an unvalidated delay scheduler, and the discussion in §V explicitly concedes that the test suite mostly stems from bugs found during development.

Significance. If the full-timing semantics are correct, Vogls would fill a genuine gap: no open-source simulator combines compiled-code speed, four-value/full-timing simulation, and interactive state forking. The forking workflow is a meaningful contribution for SCA trace collection, and the case study makes the utility concrete. The paper also provides reproducible benchmark-style measurements and a clear description of VIR. The main risk is that the full-timing model — the key differentiator over Verilator — is not validated against a reference simulator or hardware, so the full-timing MTD value and the 'more accurate timing model' claim are not yet established.

major comments (3)
  1. [§V, §III.B] The load-bearing claim that Vogls provides a 'more accurate timing model' and valid full-timing leakage results is not supported by any differential validation. §V states that the test suite 'mostly stem[s] from bugs found during development,' and no comparison against Icarus Verilog, another IEEE-1364/SDF-compliant simulator, or hardware measurements is reported. The description of lupdt/varwait in §III.B does not establish correct handling of inertial delay/pulse rejection, min:typ:max SDF selection, or timing checks. Since the full-timing MTD of 18,341 traces in Table III and the claim that glitches are modeled depend entirely on this scheduler, the authors should add differential tests against a reference simulator (e.g., Icarus) on the same ICE40 netlist and, ideally, a hardware measurement. Without this, the full-timing column of Table III may be an artifact of Vogls' timing model.
  2. [§IV.A, Table II] The headline performance comparison is stated in a way that is misleading about end-to-end cost. The '5.9x faster than Icarus Verilog' figure compares only simulation time (76.164 s vs 12.798 s) and excludes Vogls' compilation time of 93.167 s versus Icarus' 0.417 s. For a single run, Vogls is not faster; the claim is only valid when compilation is amortized over many traces. The paper should state this amortization explicitly. Additionally, 'only 30% slower than Verilator' is an overstatement: 1.799 s vs 1.441 s is 24.8% slower. Please correct the percentage and discuss the amortization caveat.
  3. [§IV.B, forking workflow] The claim that forking 'preserv[es] timing and leakage characteristics' (Abstract and §III.C) is not empirically demonstrated. The argument that the design is read-only and the entire state is copied is plausible, but a concrete equivalence check — e.g., that a forked simulation produces bit-identical signal traces to a non-forked simulation — would be straightforward and should be reported. This is particularly important because the forked workflow is one of the three headline contributions and is used for all MTD measurements in Table III.
minor comments (5)
  1. [§IV.B, Table III] MTD (Minimum Traces to Disclosure) is used without a formal definition. Define it precisely (e.g., the smallest trace count at which all 16 key bytes are ranked first) and state the attack parameters (number of key hypotheses, ranking criterion, etc.) for reproducibility.
  2. [§III.B] The text says 'a specification is available for VIR' but no URL or reference is given. Please provide a stable link or citation.
  3. [§V] The paper says the source-code repository includes a full overview of supported Verilog concepts, but no repository URL appears anywhere in the manuscript. Since the paper promises open-sourcing 'upon acceptance,' include the URL now or state clearly that it will be added.
  4. [§IV.A] The benchmark environment is described, but not the exact versions of Verilator and Icarus Verilog, nor the C compiler flags used for Vogls' native code path. State versions and flags for reproducibility.
  5. [Abstract] The phrase 'first simulator to combine...' is a strong novelty claim. It would help to cite the specific features in Table I and explicitly contrast with CVC, which is listed as efficient and versatile but not interactive. The current text does not make clear whether CVC's interactive limitations are architectural or simply unverified.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Vogls' performance and MTD claims are externally benchmarked measurements; self-citations are background only.

full rationale

The paper's central claims are empirical and self-contained against external benchmarks. Table II compares measured compile/simulate times against Verilator and Icarus Verilog on fixed workloads, and Table III reports MTD values from a DPA attack using fixed parameters (fixed target key, random plaintexts, Hamming Distance model). No parameter is fitted to produce the claimed performance ratios or attack results, and there is no equation in which one predicted quantity is defined in terms of another. The strongest caveat—that Vogls' full-timing scheduler is not differentially validated against a reference simulator—is explicitly acknowledged in Section V: 'these tests mostly stem from bugs found during development.' That is a correctness/validation gap, not a circular derivation: an incorrect scheduler could make the MTD numbers empirically wrong, but the results are not true by construction. The self-citations ([19], [31], [33], [36]) support adaptive-attack motivation, a survey, a benchmark S-box design, and a future-work metric, respectively; none is load-bearing for Vogls' performance or attack conclusions. No self-definitional, fitted-input-as-prediction, or uniqueness-imported-from-authors pattern is present.

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

Light ledger: this is a measurement/tool paper, so the central claims are benchmark timings and a DPA demonstration rather than derived predictions. No numerical parameter is fitted to data — compile/simulation times are measured, MTD values are measured attack outcomes, and no constant is adjusted to produce the results. Vogls introduces VIR, but that is a software intermediate representation with falsifiable handles (the promised open-source code, the test suite), not a physical postulate in the graviton class. The epistemic load sits on the four domain assumptions listed.

assumptions (4)
  • domain assumption IEEE 1364 Verilog scheduling semantics (event regions, delays, pre-emption) are the correct reference model for full-timing simulation leakage.
    Invoked throughout §III.B: VIR is claimed to follow 'Verilog scheduling semantics,' and the SCA value proposition rests on glitch fidelity (Mangard et al. [15]). If real chips deviate from these semantics, or Vogls deviates from them, the leakage conclusions change.
  • domain assumption The Hamming Distance power model applied to traced signal activity approximates the physical power leakage relevant to a real AES DPA attack.
    Used in §IV.B to derive traces and compute MTD; standard in SCA literature but an acknowledged abstraction — no electrical or technology power model is used.
  • domain assumption SDF/delay annotations from the ICE40 cell library give faithful full-timing data for the gate-level designs.
    Experiment (3) in §IV.A and the GTL/full-timing GTL simulations in §IV.B rely on Yosys-synthesized ICE40 netlists with timing annotations; errors in library timing would propagate directly into the MTD results.
  • domain assumption The Table I survey is complete: no existing simulator combines the three criteria.
    §II.B states 'To our knowledge, no existing Verilog simulator combines (1) efficient, (2) interactive, and (3) versatile.' The survey excludes commercial simulators on license grounds, not capability grounds, so the Abstract's 'first simulator' framing is stronger than the survey supports.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Vogls: a Fast Interactive Full-timing Simulator for Pre-silicon Power Side-Channel Analysis." pith.science (2026). https://pith.science/paper/LAGGLLN6

@misc{pith2026260715782,
  author       = {Pith},
  title        = {Pith review of: Vogls: a Fast Interactive Full-timing Simulator for Pre-silicon Power Side-Channel Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LAGGLLN6}},
  note         = {Machine review of arXiv:2607.15782}
}
read the original abstract

Designing hardware circuits resistant to side-channel attacks increasingly relies on simulation to predict device leakage before fabrication. Current functional verification simulators are designed for extended correctness-checking runs and are ill-suited for producing large numbers of short trace collections with slight input variants needed for side-channel analysis. We present Vogls: an open-source Verilog simulator built for side-channel analysis, that is the first simulator to combine compiled-code performance, full-timing simulation, and fine-grained control over the simulation state. Vogls simulates a timing annotated gate-level AES design 5.9 times faster than Icarus Verilog and is only 30% slower than Verilator on a PicoRV32 RTL design while also offering a more accurate timing model. Vogls provides a Python interface that allows simulations to be paused, forked, inspected, and mutated around points-of-interest without modifying the hardware design and thereby preserving timing and leakage characteristics. Furthermore, a trace-collection workflow runs setup code once and forks at the point-of-interest, eliminating the need to re-simulate from reset for every trace. A case study demonstrates Vogls on a differential power analysis attack that successfully recovers the key at RTL, GTL and full-timing GTL abstraction levels.

Figures

Figures reproduced from arXiv: 2607.15782 by the authors.

Figure 1
Figure 1. A block diagram of Vogls taking Verilog to bytecode or native code. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Key-byte rank of the slowest-converging byte versus number of traces [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

37 extracted references · 6 canonical work pages

  1. [1]

    Differential Power Analysis,

    P. Kocher, J. Jaffe, and B. Jun, “Differential Power Analysis,” in Advances in Cryptology — CRYPTO’ 99 , M. Wiener, Ed., Berlin, Hei - delberg: Springer, 1999, pp. 388–397. doi: 10.1007/3-540-48405-1_25

  2. [2]

    Electromagnetic Analysis: Concrete Results,

    K. Gandolfi, C. Mourtel, and F. Olivier, “Electromagnetic Analysis: Concrete Results,” in Cryptographic Hardware and Embedded Systems — CHES 2001, Ç. K. Koç, D. Naccache, and C. Paar, Eds., Berlin, Hei - delberg: Springer, 2001, pp. 251–261. doi: 10.1007/3-540-44709-1_21

  3. [3]

    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 Advances in Cryptology — CRYPTO ’96, N. Koblitz, Ed., Berlin, Heidelberg: Springer, 1996, pp. 104–113. doi: 10.1007/3-540-68697-5_9

  4. [4]

    EUCLEAK

    T. Roche, “EUCLEAK.” [Online]. Available: https://eprint.iacr.org/ 2024/1380

  5. [5]

    Side-Channel Resis - tance

    Federal Office for Information Security (BSI), “Side-Channel Resis - tance.” Accessed: Apr. 20, 2026. [Online]. Available: https://www.bsi. bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen- und-Empfehlungen/Kryptografie/Seitenkanalresistenz/seitenkanalresiste nz.html?nn=916726

  6. [6]

    A testing methodology for side-channel resistance validation,

    B. J. Gilbert Goodwill, J. Jaffe, P. Rohatgi, and others, “A testing methodology for side-channel resistance validation,” in NIST non- invasive attack testing workshop , 2011, pp. 115–136

  7. [7]

    Coco: Co- Design and Co-Verification of Masked Software Implementations on CPUs,

    B. Gigerl, V. Hadzic, R. Primas, S. Mangard, and R. Bloem, “Coco: Co- Design and Co-Verification of Masked Software Implementations on CPUs,” presented at the 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 1469–1468. Accessed: Dec. 03, 2025. [On - line]. Available: https://www.usenix.org/conference/usenixsecurity21/ presentation/gigerl

  8. [8]

    Architecture Corre - lation Analysis (ACA): Identifying the Source of Side-channel Leakage at Gate-level

    Y. Yao, T. Kathuria, B. Ege, and P. Schaumont, “Architecture Corre - lation Analysis (ACA): Identifying the Source of Side-channel Leakage at Gate-level.” Accessed: Dec. 02, 2025. [Online]. Available: https:// eprint.iacr.org/2020/1192

Show all 37 references
  1. [9]

    Power side-channel leakage assessment and locating the exact sources of leakage at the early stages of ASIC design process,

    V. Samadi Bokharaie and A. Jahanian, “Power side-channel leakage assessment and locating the exact sources of leakage at the early stages of ASIC design process,” The Journal of Supercomputing , vol. 78, no. 2, pp. 2219–2244, Feb. 2022, doi: 10.1007/s11227-021-03927-w

  2. [10]

    IEEE standard for Verilog hardware description language (IEEE 1364-2005),

    I. S. Association and others, “IEEE standard for Verilog hardware description language (IEEE 1364-2005),” http://standards. ieee. org/ , 2006

  3. [11]

    IEEE Standard for Design and Verification of Low-Power Inte - grated Circuits

    “IEEE Standard for Design and Verification of Low-Power Inte - grated Circuits.” Accessed: Apr. 14, 2026. [Online]. Available: http:// ieeexplore.ieee.org/document/6521327/

  4. [12]

    FST Format Specification

    T. Hutt, “FST Format Specification.” [Online]. Available: https://blog. timhutt.co.uk/fst_spec/

  5. [13]

    RTL to transistor level power modeling and estimation techniques for FPGA and ASIC: A survey,

    Y. Nasser, J. Lorandel, J.-C. Prévotet, and M. Hélard, “RTL to transistor level power modeling and estimation techniques for FPGA and ASIC: A survey,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , vol. 40, no. 3, pp. 479–493, 2020

  6. [14]

    Telescope: Top-Down Hierarchical Pre-silicon Side-channel Leakage Assessment in System- on-Chip Design,

    Z. Liu, A. Malnicof, A. Roy, and P. Schaumont, “Telescope: Top-Down Hierarchical Pre-silicon Side-channel Leakage Assessment in System- on-Chip Design,” in Proceedings of the 20th ACM Asia Conference on Computer and Communications Security , in ASIA CCS '25. New York, NY, USA:...

  7. [15]

    Successfully attacking masked AES hardware implementations,

    S. Mangard, N. Pramstaller, and E. Oswald, “Successfully attacking masked AES hardware implementations,” in Proceedings of the 7th international conference on Cryptographic hardware and embedded systems, in CHES'05. Berlin, Heidelberg: Springer-Verlag, Aug. 2005, pp. 157–171. ...

  8. [16]

    Icarus verilog: open-source verilog more than a year later,

    S. Williams and M. Baxter, “Icarus verilog: open-source verilog more than a year later,” Linux Journal , vol. 2002, no. 99, 2002, Accessed: Mar. 12, 2026. [Online]. Available: https://dl.acm.org/doi/10.5555/ 513581.513584

  9. [17]

    Verilator

    W. Snyder, P. Wasson, D. Galbi, G. Lore, and et al, “Verilator.” Ac - cessed: Mar. 11, 2026. [Online]. Available: https://github.com/verilator/ verilator

  10. [18]

    Cocotb: a Python-based digital logic verification frame - work

    B. Rosser, “Cocotb: a Python-based digital logic verification frame - work.”

  11. [19]

    Online template attacks,

    L. Batina, Ł. Chmielewski, L. Papachristodoulou, P. Schwabe, and M. Tunstall, “Online template attacks,” Journal of Cryptographic Engineering, vol. 9, no. 1, pp. 21–36, Apr. 2019, doi: 10.1007/ s13389-017-0171-8

  12. [20]

    CVC Verilog Compiler – Fast Complex Language Compilers Can be Simple

    S. Meyer, “CVC Verilog Compiler – Fast Complex Language Compilers Can be Simple.” Accessed: Mar. 12, 2026. [Online]. Available: http:// arxiv.org/abs/1603.08059

  13. [21]

    Yosys - A Free Verilog Synthesis Suite

    C. Wolf and J. Glaser, “Yosys - A Free Verilog Synthesis Suite.”

  14. [22]

    Openroad: Toward a self-driving, open-source digital layout implementation tool chain,

    T. Ajayi and D. Blaauw, “Openroad: Toward a self-driving, open-source digital layout implementation tool chain,” in Proceedings of Govern - ment Microcircuit Applications and Critical Technology Conference , 2019

  15. [23]

    Surfer — An Extensible Waveform Viewer,

    F. Skarman, L. Klemmer, D. Große, O. Gustafsson, and K. Laeufer, “Surfer — An Extensible Waveform Viewer,” in Computer Aided Verification, R. Piskac and Z. Rakamarić, Eds., Cham: Springer Nature Switzerland, 2025, pp. 392–404. doi: 10.1007/978-3-031-98685-7_19

  16. [24]

    MLIR: Scaling Compiler Infrastructure for Domain Specific Computation,

    C. Lattner et al., “MLIR: Scaling Compiler Infrastructure for Domain Specific Computation,” in 2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO) , Feb. 2021, pp. 2–14. doi: 10.1109/CGO51591.2021.9370308

  17. [25]

    LLVM: a compilation framework for lifelong program analysis & transformation,

    C. Lattner and V. Adve, “LLVM: a compilation framework for lifelong program analysis & transformation,” in International Symposium on Code Generation and Optimization, 2004. CGO 2004. , Mar. 2004, pp. 75–86. doi: 10.1109/CGO.2004.1281665

  18. [26]

    Reusability is FIRRTL ground: Hardware con - struction languages, compiler frameworks, and transformations,

    A. Izraelevitz et al. , “Reusability is FIRRTL ground: Hardware con - struction languages, compiler frameworks, and transformations,” in 2017 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), Nov. 2017, pp. 209–216. doi: 10.1109/ICCAD.2017.8203780

  19. [27]

    LLHD: a multi- level intermediate representation for hardware description languages,

    F. Schuiki, A. Kurth, T. Grosser, and L. Benini, “LLHD: a multi- level intermediate representation for hardware description languages,” in Proceedings of the 41st ACM SIGPLAN Conference on Programming Language Design and Implementation , in PLDI 2020. New York, NY, USA: Associ...

  20. [28]

    IEEE Standard for Standard Delay Format (SDF) for the Electronic Design Process

    “IEEE Standard for Standard Delay Format (SDF) for the Electronic Design Process.” Accessed: Apr. 14, 2026. [Online]. Available: https:// ieeexplore.ieee.org/document/972829/

  21. [29]

    AMASIVE: An Adapt - able and Modular Autonomous Side-Channel Vulnerability Evaluation Framework,

    S. A. Huss, M. Stöttinger, and M. Zohner, “AMASIVE: An Adapt - able and Modular Autonomous Side-Channel Vulnerability Evaluation Framework,” in Number Theory and Cryptography: Papers in Honor of Johannes Buchmann on the Occasion of His 60th Birthday , M. Fischlin and S. Katzen...

  22. [30]

    RTL-PSC: Automated Power Side-Channel Leakage Assessment at Register-Transfer Level,

    M. He, J. Park, A. Nahiyan, A. Vassilev, Y. Jin, and M. Tehranipoor, “RTL-PSC: Automated Power Side-Channel Leakage Assessment at Register-Transfer Level,” in 2019 IEEE 37th VLSI Test Symposium (VTS), Apr. 2019, pp. 1–6. doi: 10.1109/VTS.2019.8758600

  23. [31]

    SoK: Design Tools for Side-Channel-Aware Implementations,

    I. Buhan, L. Batina, Y. Yarom, and P. Schaumont, “SoK: Design Tools for Side-Channel-Aware Implementations,” in Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security , in ASIA CCS '22. New York, NY, USA: Association for Computing Machinery, May...

  24. [32]

    YosysHQ/picorv32

    “YosysHQ/picorv32.” Accessed: Apr. 21, 2026. [Online]. Available: https://github.com/YosysHQ/picorv32

  25. [33]

    A Very Compact

    D. Canright and L. Batina, “A Very Compact "Perfectly Masked" S-Box for AES (corrected).” Accessed: Dec. 04, 2025. [Online]. Available: https://eprint.iacr.org/2009/011

  26. [34]

    Cryptographic IP cores

    Tohoku University ECSIS Laboratory, “Cryptographic IP cores.” [Online]. Available: https://github.com/ECSIS-lab/Cryptographic- Hardware-IPs

  27. [35]

    FORTIFY: Analytical Pre- Silicon Side-Channel Characterization of Digital Designs,

    A. V. Lakshmy, C. Rebeiro, and S. Bhunia, “FORTIFY: Analytical Pre- Silicon Side-Channel Characterization of Digital Designs,” in 2022 27th Asia and South Pacific Design Automation Conference (ASP-DAC), Jan. 2022, pp. 660–665. doi: 10.1109/ASP-DAC52403.2022.9712551

  28. [36]

    Mutual Information Analysis: a Comprehensive Study,

    L. Batina, B. Gierlichs, E. Prouff, M. Rivain, F.-X. Standaert, and N. Veyrat-Charvillon, “Mutual Information Analysis: a Comprehensive Study,” Journal of Cryptology , vol. 24, no. 2, pp. 269–291, Apr. 2011, doi: 10.1007/s00145-010-9084-8

  29. [165]

    doi: 10.1007/978-3-642-42001-6_12

Pith tools

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