Pith. sign in

REVIEW 3 major objections 6 minor 1 cited by

Fun with flags: How Compilers Break and Fix Constant-Time Code

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 ↗

Pith's one-line read Disabling a small set of compiler optimization passes removes all observed compiler-introduced constant-time violations in known constant-time implementations, at negligible performance cost.

desk verdict A pass-level map of where LLVM/GCC break constant-time code that is genuinely useful and mostly convincing, but the 'removes all violations' claim outruns a validation that is in-sample and rests on a detector with known blind spots. read the letter →

arxiv 2507.06112 v1 pith:3Z2CYWJR submitted 2025-07-08 cs.CR

Antoine Geimer , Clementine Maurice This is my paper · ORCID
classification cs.CR
keywords constant-timeprogrammingtimingsidechannelscompileroptimizationsLLVMGCCloopunswitchingvectorizationconditionalmoves
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 tries to show that constant-time guarantees written into source code by cryptographic developers are being silently undone by a small, identifiable set of compiler optimization passes, and that this can be prevented without rewriting code or switching compilers. It builds a dataset of compiler-introduced constant-time violations by compiling the same benchmarks with older and newer versions of LLVM and GCC, then using a dynamic analysis tool to attribute newly appearing leaks to source lines. It isolates the responsible passes—loop unswitching, loop vectorization, and cmov conversion in LLVM; jump threading, path splitting, and loop unswitching in GCC—and shows that disabling these passes via compiler flags removes every observed compiler-introduced violation in known constant-time implementations. The payoff is practical: developers can harden existing cryptographic builds with a handful of flags and pay a negligible average performance penalty.

What carries the argument

The central object is the optimization pipeline that turns constant-time source patterns into secret-dependent control flow. In LLVM the chain runs: bit-mask arithmetic is collapsed by the InstCombine pass into a select IR instruction; loop unswitching treats the select as a loop-invariant condition and hoists it into a branch; loop vectorization duplicates the loop into vectorized and scalar epilogue versions, and the back-end lowers select to a conditional jump because x86 lacks a vector conditional-move; and the cmov conversion pass in the x86 back-end rewrites even scalar conditional moves back into branches when it predicts the branch well. In GCC, constant-time ternary operators are represented as conditional branches in GIMPLE, and jump threading, path splitting, and loop unswitching can reshape those branches so the if-conversion pass can no longer linearize them into conditional moves. The mechanism that carries the argument is pass-by-pass attribution: each leak is traced to a specific pass or interaction, then the pass is disabled via a flag and the leak disappears.

What would settle it

Compile a larger, independent set of constant-time cryptographic implementations with the proposed flag sets and analyze the resulting binaries with a sound static constant-time checker or with exhaustive dynamic tracing; any secret-dependent branch or memory access that appears in the binary but not in the source would show that the flag set does not remove all compiler-introduced violations.

Watch

Extended reading notes

Core claim

The central claim is that a small set of compiler optimization passes, and the interactions between them, are at the root of nearly all compiler-introduced constant-time violations, and that disabling these specific passes with available or undocumented compiler flags eliminates the violations. In LLVM, constant-time bit-mask arithmetic is simplified into select instructions, which then become secret-dependent branches through a combination of loop unswitching, loop vectorization (which lacks a vector conditional-move instruction and lowers select to branches), and the x86 back-end's cmov conversion pass. In GCC, constant-time ternary expressions are represented as conditional branches by default, and jump threading, path splitting, and loop unswitching can reshape those branches so the if-conversion pass can no longer turn them into conditional moves. The paper demonstrates on its benchmark suite—including BearSSL, MbedTLS, and known toy examples such as the Kyber poly_frommsg leak—that disabling these passes removes all compiler-introduced constant-time violations while keeping average performance overhead near zero.

Load-bearing premise

The analysis assumes that the set of leaks found by running the dynamic analysis tool with 16 random secret inputs and mapping reported vulnerable instructions to source lines via DWARF debug information accurately captures every compiler-introduced constant-time violation; if any leak is missed or misattributed, the identified pass set and the all-violations-removed claim are incomplete.

Editorial extensions

If this is right

  • Cryptographic libraries compiled with the proposed flag sets will no longer have the specific compiler-introduced leaks found in this study, without any source changes.
  • The same flag-based approach can be folded into build systems and distribution packaging for both GCC and LLVM, making it immediately deployable.
  • Keeping loop vectorization enabled in LLVM is insufficient for full protection (the RSA-bearssl benchmark remains vulnerable), so the full flag set is required for the claimed guarantee.
  • The negligible measured performance impact suggests the mitigation is viable for production use, not just for research artifacts.
  • Because the claim is benchmark-scoped, the flag set should be revalidated when compilers add new passes or change existing ones.

Reading between the lines

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

  • The same pass-disabling recipe could be adapted to other compilers and back-ends by identifying the equivalent passes (for example, in MSVC or in LLVM-based front-ends), but the mapping would need its own empirical validation.
  • The paper's finding that pass interactions can both break and restore constant-time behavior implies that future compiler updates might fix some leaks while creating others; a pass-by-pass detection tool run after each compiler release would be a natural follow-up.
  • If the flag set is adopted widely, it may reduce the incentive for compiler maintainers to add constant-time preservation features, since developers could simply disable the offending passes; the trade-off between performance and security would then be decided by flag policy rather than compiler design.
  • The benchmark-scoped nature of the claim suggests that high-assurance settings should combine the flag set with a sound static analysis of the final binary before deployment, rather than trusting the flag set alone.
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 / 6 minor

Summary. The paper studies how compiler optimizations in GCC and LLVM introduce constant-time (CT) violations into cryptographic code. It constructs a dataset of compiler-introduced violations by compiling CT benchmarks with older and newer compiler versions and comparing vulnerable source lines reported by the dynamic analysis tool Microwalk. Using Compiler Explorer toggling and manual inspection, the authors attribute the observed violations to a small set of passes: loop unswitching, loop vectorization, and cmov conversion in LLVM; and jump threading, path splitting, and loop unswitching in GCC. They propose disabling these passes via compiler flags and evaluate the mitigation on the same benchmark, reporting that all compiler-introduced violations are removed with low average performance overhead. The paper also discusses related work, recommendations, and limitations.

Significance. If the pass-level attribution is correct, the paper offers immediately actionable guidance for hardening real cryptographic builds without source changes or compiler forks. The analysis of pass interactions, especially the LLVM pipeline interactions and the GCC if-conversion miss, is a valuable refinement over version-level comparisons. The artifact is provided, and the evaluation covers two major compilers. However, the central claims—that the proposed flag set removes 'all' compiler-introduced violations and that the performance cost is 'negligible'—are currently under-supported because the validation is in-sample and rests on a dynamic detector with known false negatives. The paper would be a solid contribution if these claims were scoped to the observed benchmark or backed by out-of-sample validation.

major comments (3)
  1. [Section V-A, Table III; Section VII Conclusion] The central claim that disabling the identified passes 'removes all compiler-introduced vulnerabilities in known constant-time implementations' is validated only by re-running Microwalk on the same benchmark that was used to identify the pass set. Because the flag set is derived from the vulnerabilities observed in this benchmark (Section IV), the before/after comparison largely restates the selection criterion. Section VI-E already concedes that 'there may exist other passes or interactions that introduce vulnerabilities but were not observed in our current benchmarks,' so the 'all' formulation should be scoped to observed violations, or the authors should add an out-of-sample validation (e.g., a held-out CT benchmark or a sound static analysis of the mitigated binaries). Without that, the headline conclusion overstates the evidence.
  2. [Section III-B, III-C, and V-A] The evaluation relies entirely on Microwalk with 16 random secret inputs, a dynamic detector whose false negatives the authors explicitly acknowledge: 'Microwalk can miss leakages not covered by the traces' and some vulnerabilities can 'obscure' others. The absence of reported violations in the mitigated binaries therefore does not establish the absence of actual compiler-introduced violations. This concern is independent of the in-sample selection issue and compounds it: the same limited detector is used both to find the leaks and to certify their removal. To support an 'all violations removed' claim, the authors should either use a substantially larger secret-input corpus, adopt a complementary sound static analysis on the mitigated binaries, or explicitly rephrase the claim as 'no violations detected by our setup.'
  3. [Section V-B, Table IV] The conclusion that performance overhead is 'negligible' is not supported by the full-mitigation numbers. For LLVM without vectorization, Table IV reports per-benchmark degradations of -16.52% for ChaCha20 (ct), -11.97% for ECDSA, and -9.77% for GHASH, with a BearSSL mean of -3.30% and SD=8.22. A mean close to zero with large variance is not a negligible impact for cryptographic primitives where every percent matters. The paper should report and discuss these outliers, and the abstract and conclusion should be qualified accordingly (e.g., 'low average overhead' with the caveat of important per-benchmark exceptions).
minor comments (6)
  1. [Section IV-B] The text 'GGC does not internally represent conditional moves so easily' contains a typo: 'GGC' should be 'GCC.'
  2. [Section V-B] The sentence reporting MbedTLS results reads 'with and with vectorization respectively'; this should be 'with and without vectorization respectively.'
  3. [Section V-A] The phrase 'answering the first part of of RQ3' contains a doubled 'of' and should be corrected.
  4. [Abstract and Section I] The novelty statement 'we are also the first to characterize how the interactions between these passes contribute to leakage' should be tempered or more precisely dated, given the concurrent work cited as [27] and [51]; at minimum, specify exactly which interaction-level results are new.
  5. [Figure 2] The diagram in Figure 2 would be much easier to interpret with a caption explaining the two pathways and the meaning of the labels 'IR select,' 'GIMPLE if,' 'cmov,' and 'jmp'; currently the figure is cryptic without the surrounding text.
  6. [Section III-B] The sentence 'The anonymized artifact can be found at here:' needs a grammatical fix, e.g., 'can be found here:'.

Circularity Check

1 steps flagged · score 6.0 of 10

Mitigation evaluation is in-sample: the flags are selected from the very benchmark leaks they are then shown to remove, so the 'removes all violations' result is close to a restatement of the pass-selection procedure.

  1. fitted input called prediction [Section V-A (Table III), with method from Section III-C and the pass identification in Section IV; conclusion in Section VII]
    "Our benchmark allowed us to identify precisely a set of problematic optimizations in both LLVM and GCC. ... We recompile the benchmark used in Section III using Clang 18 and GCC 13, with our mitigating set of flags. ... We run Microwalk on the generated binaries, following the same setup as in Section III-B. Results. ... For both LLVM and GCC, we are able to remove all the constant-time violations the compilers we studied added in CT source code."

    The disabling set is not chosen independently: the same benchmark is first used in Section III-C to find violations (Microwalk, 16 random secrets), then Section IV attributes those exact violations to passes, and Section V disables those passes and reruns Microwalk on the same benchmark. The 'removes all' result therefore re-checks that the selected pass set covers the already-observed leaks; it is not an out-of-sample test of the sufficiency claim. Because the flag set was deduced from the same violations used in the evaluation, the observed reduction is forced up to the correctness of the manual pass attribution, rather than providing independent predictive evidence. The paper's own Section VI-E acknowledges no guarantee of completeness, consistent with the claim being benchmark-scoped.

full rationale

The central circularity is the in-sample validation of the mitigation. The paper first builds a dataset of compiler-introduced violations by running Microwalk on a fixed benchmark, then manually attributes those violations to specific optimization passes, then disables exactly those passes and reruns Microwalk on the same fixed benchmark. The claim that the flags 'remove all the constant-time violations the compilers we studied added in CT source code' is therefore a re-statement of the selection procedure in a slightly different guise: the pass set was chosen to cover the observed leaks, and the evaluation confirms that the observed leaks are covered. This is the 'fitted input called prediction' pattern rather than a definitional identity, since the manual pass attribution could in principle be wrong and the performance measurements are independent. The paper is transparent about the benchmark-scoped nature of the claim: Section VI-E states that 'there may exist other passes or interactions that introduce vulnerabilities but were not observed in our current benchmarks,' which correctly bounds the conclusion but does not cure the in-sample evaluation. Independent content does exist: the Compiler Explorer-based pass analysis in Section IV provides mechanistic explanations (loop unswitching turning select IR into a branch, vectorization duplicating loops, cmov conversion lowering selects to branches), and several toy benchmarks come from external bug reports. These give the paper real value beyond the fit, but they do not support the 'all violations removed' claim as an independent prediction. The citations to prior work, including the authors' own [26], are used for benchmark provenance and tool choices rather than as load-bearing justifications of the central claim, so they do not add circularity. Overall, the result is partially circular because the central 'removes all' claim reduces to an in-sample fit; score 6 rather than 8 or 10 because no definitional equivalence or self-citation chain is involved and the mechanistic analysis retains independent content.

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

This empirical study introduces no mathematical free parameters, but it does rely on unverified assumptions about benchmark CT status, dynamic detection completeness, and DWARF line mapping. The mitigation pass set is listed as a free parameter because it is the main hand-chosen input to the central claim and is fitted to the observed leaks.

free parameters (1)
  • Disabled optimization pass set (per compiler) = LLVM: x86-cmov-converter, CodeGenPrepare select2branch, loop unswitching threshold, -fno-vectorize; GCC…
    The set of passes to disable is chosen after inspecting the leaks observed in the benchmark, then validated on that same benchmark. It is the main hand-selected input to the mitigation claim.
assumptions (4)
  • domain assumption The selected BearSSL and MbedTLS functions are truly constant-time at source level.
    Used as ground truth in Section III-B, based on prior tool evaluation [26], not re-verified in this paper.
  • domain assumption Microwalk with 16 random secret inputs detects the relevant constant-time violations and does not report false positives on the identified lines.
    The comparison metric in Section III-C counts reported vulnerable lines; missed traces or obscured vulnerabilities would break the older-versus-newer comparison.
  • domain assumption DWARF debug information accurately maps each vulnerable instruction to its originating source line.
    Assumed in Section III-B when comparing binaries from different compiler versions at line granularity.
  • domain assumption Increases in vulnerable source lines between older and newer compiler versions are caused by compiler optimizations rather than by changes in measurement conditions.
    This is the core differential methodology in Section III-A; if false, the dataset of compiler-introduced violations is contaminated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Fun with flags: How Compilers Break and Fix Constant-Time Code." pith.science (2026). https://pith.science/paper/3Z2CYWJR

@misc{pith2026250706112,
  author       = {Pith},
  title        = {Pith review of: Fun with flags: How Compilers Break and Fix Constant-Time Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3Z2CYWJR}},
  note         = {Machine review of arXiv:2507.06112}
}
read the original abstract

Developers rely on constant-time programming to prevent timing side-channel attacks. But these efforts can be undone by compilers, whose optimizations may silently reintroduce leaks. While recent works have measured the extent of such leakage, they leave developers without actionable insights: which optimization passes are responsible, and how to disable them without modifying the compiler remains unclear. In this paper, we conduct a qualitative analysis of how compiler optimizations break constant-time code. We construct a dataset of compiler-introduced constant-time violations and analyze the internals of two widely used compilers, GCC and LLVM, to identify the specific optimization passes responsible. Our key insight is that a small set of passes are at the root of most leaks. To the best of our knowledge, we are also the first to characterize how the interactions between these passes contribute to leakage. Based on this analysis, we propose an original and practical mitigation that requires no source code modification or custom compiler: disabling selected optimization passes via compiler flags. We show that this approach significantly reduces leakage with minimal performance overhead, offering an immediately deployable defense for developers.

Figures

Figures reproduced from arXiv: 2507.06112 by the authors.

Figure 1
Figure 1. Secret-dependent control-flow and memory accesses [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Pathways to breaking CT in LLVM (left) and GCC [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Vulnerable snippet in RSA-bearssl. time. Indeed this depends entirely on whether the select IR instruction is kept by further optimizations and whether the x86-64 back-end lowers it into a constant-time cmov. In the rest of this section, we show that this is not always the case, highlighting the need for our fine-grain analysis. To help us understand how, let us consider two examples of compiler-introduced CT violat… view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Decompiling for Constant-Time Analysis

    cs.PL 2025-01 conditional novelty 8.0 of 10 partial

    Decompilation can silently erase constant-time violations, so the paper defines CT transparency and builds CT-RetDec, a RetDec variant that finds violations other decompilers miss.

Reference graph

Works this paper leans on

52 extracted references · 52 canonical work pages · cited by 1 Pith paper

  1. [1]

    Predicting secret keys via branch prediction

    Onur Aciic ¸mez, C ¸ etin Kaya Koc ¸, and Jean-Pierre Seifert. Predicting secret keys via branch prediction. In CT-RSA, 2007

    work page 2007

  2. [2]

    Rao, and Pankaj Rohatgi

    Dakshi Agrawal, Bruce Archambeault, Josyula R. Rao, and Pankaj Rohatgi. The EM side-channel(s). In Burton S. Kaliski Jr., C ¸ etin Kaya Koc ¸, and Christof Paar, editors,CHES, 2002

    work page 2002

  3. [3]

    Port contention for fun and profit

    Alejandro Cabrera Aldaya, Billy Bob Brumley, Sohaib ul Hassan, Cesar Pereida Garc ´ıa, and Nicola Tuveri. Port contention for fun and profit. In S&P, 2019

    work page 2019

  4. [4]

    Bacelar Almeida, M

    J. Bacelar Almeida, M. Barbosa, G. Barthe, A. Blot, B. Gr ´egoire, V . Laporte, T. Oliveira, H. Pacheco, B. Schmidt, and P.-Y . Strub. Jasmin: High-assurance and high-speed cryptography. In CCS, 2017

    work page 2017

  5. [5]

    Formal verification of a constant-time preserving C compiler

    Gilles Barthe, Sandrine Blazy, Benjamin Gr ´egoire, R´emi Hutin, Vincent Laporte, David Pichardie, and Alix Trieu. Formal verification of a constant-time preserving C compiler. POPL, 2020

    work page 2020

  6. [6]

    Secure com- pilation of side-channel countermeasures: The case of cryptographic ”constant-time”

    Gilles Barthe, Benjamin Gr ´egoire, and Vincent Laporte. Secure com- pilation of side-channel countermeasures: The case of cryptographic ”constant-time”. In CSF, 2018

    work page 2018

  7. [7]

    Cache-timing attacks on AES, 2005

    Daniel J Bernstein. Cache-timing attacks on AES, 2005

    work page 2005

  8. [8]

    Bernstein, Karthikeyan Bhargavan, Shivam Bhasin, Anupam Chattopadhyay, Tee Kiah Chia, Matthias J

    Daniel J. Bernstein, Karthikeyan Bhargavan, Shivam Bhasin, Anupam Chattopadhyay, Tee Kiah Chia, Matthias J. Kannwischer, Franziskus Kiefer, Thales B. Paiva, Prasanna Ravi, and Goutam Tamvada. Ky- berSlash: Exploiting secret-dependent division timings in Kyber imple- mentations. TCHES, 2025

    work page 2025

Show all 52 references
  1. [9]

    Constantine: Automatic side-channel resistance using efficient control and data flow linearization

    Pietro Borrello, Daniele Cono D’Elia, Leonardo Querzoni, and Cristiano Giuffrida. Constantine: Automatic side-channel resistance using efficient control and data flow linearization. In CCS, 2021

    2021

  2. [10]

    B. B. Brumley and R. M. Hakala. Cache-timing template attacks. In ASIACRYPT, 2009

    2009

  3. [11]

    Bug 113682 - branches in branchless binary search rather than cmov/csel/csinc

    GCC Bugzilla. Bug 113682 - branches in branchless binary search rather than cmov/csel/csinc. https://gcc.gnu.org/bugzilla/show bug.cgi? id=113682

  4. [12]

    Bug 68541 - [6 regression] path splitting causes if- conversion miss

    GCC Bugzilla. Bug 68541 - [6 regression] path splitting causes if- conversion miss. https://gcc.gnu.org/bugzilla/show bug.cgi?id=68541

  5. [13]

    Wahby, John Renner, Benjamin Gr ´egoire, Gilles Barthe, Ranjit Jhala, and Deian Stefan

    Sunjay Cauligi, Gary Soeller, Brian Johannesmeyer, Fraser Brown, Riad S. Wahby, John Renner, Benjamin Gr ´egoire, Gilles Barthe, Ranjit Jhala, and Deian Stefan. Fact: a DSL for timing-sensitive computation. In PLDI, 2019

    2019

  6. [14]

    Symbolic verification of cache side-channel freedom

    Sudipta Chattopadhyay and Abhik Roychoudhury. Symbolic verification of cache side-channel freedom. Trans. Comput. Aided Des. Integr . Circuits Syst., 2018

    2018

  7. [15]

    Binsec/rel: Efficient relational symbolic execution for constant-time at binary-level

    Lesly-Ann Daniel, S ´ebastien Bardin, and Tamara Rezk. Binsec/rel: Efficient relational symbolic execution for constant-time at binary-level. In S&P, 2020

    2020

  8. [16]

    Optimize options

    GCC development team. Optimize options. https://gcc.gnu.org/ onlinedocs/gcc/Optimize-Options.html

  9. [17]

    Auto-vectorization in llvm

    LLVM development team. Auto-vectorization in llvm. https://llvm.org/ docs/Vectorizers.html

  10. [18]

    llvm::simpleloopunswitchpass class refer- ence

    LLVM development team. llvm::simpleloopunswitchpass class refer- ence. https://llvm.org/doxygen/classllvm 1 1SimpleLoopUnswitchPass. html

  11. [19]

    X86cmovconversion.cpp file reference

    LLVM development team. X86cmovconversion.cpp file reference. https: //llvm.org/doxygen/X86CmovConversion 8cpp.html

  12. [20]

    Fletcher

    Sushant Dinesh, Grant Garrett-Grossman, and Christopher W. Fletcher. Synthct: Towards portable constant-time code. In NDSS, 2022

    2022

  13. [21]

    Disselkoen, S

    C. Disselkoen, S. Cauligi, D. Tullsen, and D. Stefan. Finding and eliminating timing side-channels in crypto code with pitchfork. In TECHCON, 2020

    2020

  14. [22]

    Semi-automated and Easily Interpretable Side-Channel Analysis for Modern JavaScript

    Iliana Fayolle, Jan Wichelmann, Anja K ¨ohl, Walter Rudametkin, Thomas Eisenbarth, and Cl ´ementine Maurice. Semi-automated and Easily Interpretable Side-Channel Analysis for Modern JavaScript. In CANS, 2024

    2024

  15. [23]

    Mbed TLS

    Trusted Firmware. Mbed TLS. https://www.trustedfirmware.org/ projects/mbed-tls/

  16. [24]

    Sharma, Alexandra E

    Michael Flanders, Reshabh K. Sharma, Alexandra E. Michael, Dan Grossman, and David Kohlbrenner. Avoiding instruction-centric mi- croarchitectural timing channels via binary-code transformations. In ASPLOS (2) , 2024

    2024

  17. [25]

    ”these results must be false”: A usability evaluation of constant-time analysis tools

    Marcel Fourn ´e, Daniel De Almeida Braga, Jan Jancar, Mohamed Sabt, Peter Schwabe, Gilles Barthe, Pierre-Alain Fouque, and Yasemin Acar. ”these results must be false”: A usability evaluation of constant-time analysis tools. In USENIX Security Symposium , 2024

    2024

  18. [26]

    A systematic evaluation of automated tools for side-channel vulnerabilities detection in cryptographic libraries

    Antoine Geimer, Math ´eo Vergnolle, Fr ´ed´eric Recoules, Lesly-Ann Daniel, S ´ebastien Bardin, and Cl ´ementine Maurice. A systematic evaluation of automated tools for side-channel vulnerabilities detection in cryptographic libraries. In CCS, 2023

    2023

  19. [27]

    Do Compilers Break Constant-time Guarantees? In Financial Cryptography, 2025

    Lukas Gerlach, Robert Pietsch, and Michael Schwarz. Do Compilers Break Constant-time Guarantees? In Financial Cryptography, 2025

    2025

  20. [28]

    Compiler explorer

    Matt Godbolt. Compiler explorer. https://github.com/compiler-explorer/ compiler-explorer

  21. [29]

    Side-channel analysis of cryptographic software via early-terminating multiplications

    Johann Großsch ¨adl, Elisabeth Oswald, Dan Page, and Michael Tunstall. Side-channel analysis of cryptographic software via early-terminating multiplications. In ICISC, 2009

    2009

  22. [30]

    Request for a conditional move built-in function

    Jeff Hurchalla. Request for a conditional move built-in function. GCC Bugzilla, https://gcc.gnu.org/bugzilla/show bug.cgi?id=98801

  23. [31]

    Cache attacks enable bulk key recovery on the cloud

    Mehmet Sinan Inci, Berk G ¨ulmezoglu, Gorka Irazoqui, Thomas Eisen- barth, and Berk Sunar. Cache attacks enable bulk key recovery on the cloud. In CHES, 2016

    2016

  24. [32]

    Guidelines for Mitigating Timing Side Channels Against Cryp- tographic Implementations

    Intel. Guidelines for Mitigating Timing Side Channels Against Cryp- tographic Implementations. https://www.intel.com/content/www/us/en/ developer/articles/technical/software-security-guidance/secure-coding/ mitigate-timing-side-channel-crypto-implementation.html

  25. [33]

    ”they’re not that hard to mitigate”: What cryptographic library develop- ers think about timing attacks

    Jan Jancar, Marcel Fourn ´e, Daniel De Almeida Braga, Mohamed Sabt, Peter Schwabe, Gilles Barthe, Pierre-Alain Fouque, and Yasemin Acar. ”they’re not that hard to mitigate”: What cryptographic library develop- ers think about timing attacks. In S&P, 2022

    2022

  26. [34]

    P. C. Kocher, J. Jaffe, and B. Jun. Differential power analysis. In CRYPTO, 1999

    1999

  27. [35]

    ct choose: Constant-time choose between two variables

    lmrs2. ct choose: Constant-time choose between two variables. https: //github.com/lmrs2/ct choose

  28. [36]

    A survey of microarchitectural side-channel vulnerabilities, attacks, and defenses in cryptography

    Xiaoxuan Lou, Tianwei Zhang, Jun Jiang, and Yinqian Zhang. A survey of microarchitectural side-channel vulnerabilities, attacks, and defenses in cryptography. ACM Comput. Surv. , 2022

    2022

  29. [37]

    Transparent decompilation for timing side- channel analyses

    Santiago Arranz Olmos, Gilles Barthe, Lionel Blatter, S ¨oren van der Wall, and Zhiyuan Zhang. Transparent decompilation for timing side- channel analyses. CoRR, abs/2501.04183, 2025

    2025 arXiv

  30. [38]

    Cache Missing for Fun and Profit

    Colin Percival. Cache Missing for Fun and Profit. In BSDCan, 2005

    2005

  31. [39]

    Thomas Pornin. BearSSL. https://bearssl.org/

  32. [40]

    Constant-time code: The pessimist case

    Thomas Pornin. Constant-time code: The pessimist case. Cryptology ePrint Archive, Paper 2025/435, 2025

    2025

  33. [41]

    Compiler-introduced timing leak in Kyber reference implementation

    Antoon Purnal. Compiler-introduced timing leak in Kyber reference implementation. https://groups.google.com/a/list.nist.gov/g/pqc-forum/ c/hqbtIGFKIpU, 2024

    2024

  34. [42]

    Breaking bad: How compilers break constant- time˜implementations

    Moritz Schneider, Daniele Lain, Ivan Puddu, Nicolas Dutly, and Srdjan Capkun. Breaking bad: How compilers break constant- time˜implementations. CoRR, abs/2410.13489, 2024

    2024 arXiv

  35. [43]

    Chan Kim, D

    Y-j Shin, H. Chan Kim, D. Kwon, J-H Jeong, and J. Hur. Unveiling hardware-based data prefetcher, a hidden source of information leakage. In CCS, 2018

    2018

  36. [44]

    Anderson

    Laurent Simon, David Chisnall, and Ross J. Anderson. What you get is what you C: controlling side effects in mainstream C compilers. In EuroS&P, 2018

    2018

  37. [45]

    Side-channel resistant values

    Daan Sprenkels. Side-channel resistant values. llvm-dev mailing list, https://lists.llvm.org/pipermail/llvm-dev/2019-September/135079.html

    2019

  38. [46]

    Stallman and the GCC Developer Community

    Richard M. Stallman and the GCC Developer Community. GNU compiler collection internals. https://gcc.gnu.org/onlinedocs/gcc-14.2. 0/gccint.pdf

  39. [47]

    Wichelmann, F

    J. Wichelmann, F. Sieck, A. P ¨atschke, and T. Eisenbarth. Microwalk-ci: Practical side-channel analysis for javascript applications. In CCS, 2022

    2022

  40. [48]

    Microwalk: A framework for finding side channels in binaries

    Jan Wichelmann, Ahmad Moghimi, Thomas Eisenbarth, and Berk Sunar. Microwalk: A framework for finding side channels in binaries. In ACSAC, 2018

    2018

  41. [49]

    Silent Bugs Matter: A Study of Compiler- Introduced Security Bugs

    Jianhao Xu, Kangjie Lu, Zhengjie Du, Zhu Ding, Linke Li, Qiushi Wu, Mathias Payer, and Bing Mao. Silent Bugs Matter: A Study of Compiler- Introduced Security Bugs. In USENIX Security , 2023

    2023

  42. [50]

    FLUSH+RELOAD: A high reso- lution, low noise, L3 cache side-channel attack

    Yuval Yarom and Katrina Falkner. FLUSH+RELOAD: A high reso- lution, low noise, L3 cache side-channel attack. In USENIX Security , 2014

    2014

  43. [51]

    CT-LLVM: Automatic Large-Scale Constant-Time Analysis

    Zhiyuan Zhang and Gilles Barthe. CT-LLVM: Automatic Large-Scale Constant-Time Analysis. IACR Cryp. ePrint , 2025

    2025

  44. [52]

    J. K. Zinzindohou ´e, K. Bhargavan, J. Protzenko, and B. Beurdouche. Hacl*: A verified modern cryptographic library. In CCS, 2017. APPENDIX Impact of unrolling. Table V shows the impact of loop unrolling on the number of vulnerabilities found in binaries following two metrics:...

    2017

Pith tools

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