pith. sign in

arxiv: 1907.02530 · v1 · pith:NORESIZQnew · submitted 2019-07-04 · 💻 cs.CR

Security Implications Of Compiler Optimizations On Cryptography -- A Review

A. P. Shivarpatna Venkatesh , A. Bhat Handadi , M. Mory This is my paper

Pith reviewed 2026-05-25 09:05 UTC · model grok-4.3

classification 💻 cs.CR
keywords compiler optimizationscryptographysecurity requirementsC languagesecure coding practicesliterature reviewcryptographic librariessecret data erasure
0
0 comments X

The pith

Compiler optimizations can violate security requirements like secret erasure in C-based cryptographic code.

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

This literature review establishes that security requirements such as erasing secret data after use and guaranteeing real-time execution are not part of the C language, allowing compiler optimizations to remove or alter them. Developers therefore rely on indirect workarounds that conceal code semantics from the compiler, yet these tactics lose effectiveness as optimizations grow more powerful and render earlier secure implementations vulnerable. The paper surveys the resulting security complications, catalogs mitigation techniques in use, reviews academic proposals for letting programmers state security needs explicitly to compilers, and examines how six cryptographic libraries currently handle the issue. A reader would care because the review shows that performance tools can silently undermine the very security properties they are meant to protect in production crypto systems.

Core claim

The central claim is that compiler optimizations create security complications for cryptography because requirements such as secret-data erasure and real-time execution are not explicitly captured by the C language and can be violated by optimizations. Developers therefore employ workarounds to hide semantics from the compiler, but these workarounds are not permanent solutions since more efficient optimizations make code previously considered secure now vulnerable. The review covers the complications, mitigation approaches, recent efforts to communicate implicit security requirements to compilers, and a short study of six cryptographic libraries.

What carries the argument

The mismatch between implicit security requirements (secret erasure, real-time execution) and C language semantics that permits compiler optimizations to violate them.

If this is right

  • Workarounds that hide code semantics from the compiler lose reliability as optimizations advance.
  • Academic efforts focus on mechanisms allowing security engineers to express implicit requirements directly to the compiler.
  • Examination of six cryptographic libraries reveals inconsistent handling of these optimization risks.
  • Collaboration between software developers and compiler designers is needed to create systems for writing secure software efficiently.

Where Pith is reading between the lines

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

  • Language extensions or new pragmas could allow security annotations that survive optimization passes.
  • Similar risks may appear in other languages whose compilers perform aggressive dead-code elimination.
  • A practical test would be to recompile older crypto libraries with the latest optimizer versions and check whether secret-clearing code disappears.
  • The review implies that performance-security trade-offs may require explicit compiler support rather than continued reliance on ad-hoc tricks.

Load-bearing premise

Security requirements such as erasure of secret data after use and real-time execution are not explicitly captured by the C language and could potentially be violated by compiler optimizations.

What would settle it

Inspection of generated assembly from a current optimizing C compiler on a cryptographic routine containing an explicit secret-zeroing loop that shows the zeroing instructions have been removed or reordered.

read the original abstract

When implementing secure software, developers must ensure certain requirements, such as the erasure of secret data after its use and execution in real time. Such requirements are not explicitly captured by the C language and could potentially be violated by compiler optimizations. As a result, developers typically use indirect methods to hide their code's semantics from the compiler and avoid unwanted optimizations. However, such workarounds are not permanent solutions, as increasingly efficient compiler optimization causes code that was considered secure in the past now vulnerable. This paper is a literature review of (1) the security complications caused by compiler optimizations, (2) approaches used by developers to mitigate optimization problems, and (3) recent academic efforts towards enabling security engineers to communicate implicit security requirements to the compiler. In addition, we present a short study of six cryptographic libraries and how they approach the issue of ensuring security requirements. With this paper, we highlight the need for software developers and compiler designers to work together in order to design efficient systems for writing secure software.

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

1 major / 2 minor

Summary. The paper is a literature review on the security implications of compiler optimizations for cryptographic implementations in C. It discusses how optimizations can violate requirements like secret data erasure and real-time (constant-time) execution, which are not captured in the C language. The review covers (1) complications caused by optimizations, (2) developer workarounds to prevent unwanted optimizations, (3) academic efforts to allow communication of security requirements to compilers, and includes a short study of six cryptographic libraries' approaches. The authors argue that workarounds are not permanent as optimizations improve and call for collaboration between developers and compiler designers.

Significance. If the coverage of the literature is representative, this review provides a useful synthesis of known issues at the compiler-security interface in cryptography. The inclusion of the library study adds practical insight into current practices. It could serve as a starting point for researchers interested in language-level solutions for secure coding.

major comments (1)
  1. Abstract: The claim that 'increasingly efficient compiler optimization causes code that was considered secure in the past now vulnerable' is central to the motivation. The paper should cite specific instances from the reviewed literature where a workaround was invalidated by a new optimization pass, to substantiate this as an observed trend rather than a general assertion.
minor comments (2)
  1. The title uses inconsistent capitalization: 'On Cryptography -- A Review'.
  2. Abstract: The phrase 'real time execution' should be clarified as 'constant-time execution' or 'timing side-channel resistance' for precision in the cryptographic context.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive comment and the positive overall assessment of the paper. We address the single major comment below.

read point-by-point responses

  1. Referee: Abstract: The claim that 'increasingly efficient compiler optimization causes code that was considered secure in the past now vulnerable' is central to the motivation. The paper should cite specific instances from the reviewed literature where a workaround was invalidated by a new optimization pass, to substantiate this as an observed trend rather than a general assertion.

    Authors: We agree that the abstract presents the claim in general terms and that explicit citations of invalidated workarounds would strengthen the motivation. The body of the review already discusses multiple papers that document how evolving optimizations (e.g., more aggressive dead-store elimination or improved constant propagation) have rendered prior mitigation techniques ineffective. In the revised version we will add concrete citations to such instances drawn from the surveyed literature, both in the abstract and in the relevant sections on complications and workarounds. This will be a straightforward addition of references already covered in the review. revision: yes

Circularity Check

0 steps flagged

No significant circularity

full rationale

The paper is a literature review summarizing known compiler-optimization issues for cryptographic properties such as secret erasure and constant-time execution, along with developer workarounds and academic proposals drawn from external citations. It includes a short survey of six libraries but presents no derivations, equations, fitted parameters, predictions, or self-referential claims. All central observations are attributed to cited literature rather than internal constructions that reduce to the paper's own inputs by definition or self-citation.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This is a review paper; no new free parameters, axioms, or invented entities are introduced.

pith-pipeline@v0.9.0 · 5711 in / 930 out tokens · 30909 ms · 2026-05-25T09:05:49.319955+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

23 extracted references · 23 canonical work pages

  1. [1]

    Programming languages — C — ISO/IEC 9899:1999

    1999. Programming languages — C — ISO/IEC 9899:1999 . International Organiza- tion for Standardization. https://www.iso.org/standard/29237.html

    work page 1999

  2. [2]

    Pierce, Marco Stronati, and Andrew Tolmach

    Carmine Abate, Arthur Azevedo de Amorim, Roberto Blanco, Ana Nora Evans, Guglielmo Fachini, Catalin Hritcu, ThÃľo Laurent, Benjamin C. Pierce, Marco Stronati, and Andrew Tolmach. [n. d.]. When Good Components Go Bad: Formally Secure Compilation Despite Dynamic Compromise. ([n. d.]). arXiv:cs/1802.00588 http://arxiv.org/abs/1802.00588

    work page arXiv

  3. [3]

    Bearssl. [n. d.]. ccopy.c. https://www.bearssl.org/gitweb/?p=BearSSL;a=blob;f= src/codec/ccopy.c

    work page

  4. [4]

    Bearssl. [n. d.]. inner.h. https://www.bearssl.org/gitweb/?p=BearSSL;a=blob;f= src/inner.h

    work page

  5. [5]

    Bearssl. [n. d.]. Memory Wiping. https://bearssl.org/api1.html

    work page

  6. [6]

    Sunjay Cauligi, Gary Soeller, Fraser Brown, Brian Johannesmeyer, Yunlu Huang, Ranjit Jhala, and Deian Stefan. [n. d.]. FaCT: A Flexible, Constant-Time Program- ming Language. In 2017 IEEE Cybersecurity Development (SecDev) (2017-09). IEEE, 69–76. https://doi.org/10.1109/SecDev.2017.24

    work page doi:10.1109/secdev.2017.24 2017

  7. [7]

    Crypto++. [n. d.]. misc.cpp. https://github.com/weidai11/cryptopp/blob/master/ misc.cpp

    work page

  8. [8]

    Crypto++. [n. d.]. misc.h. https://github.com/weidai11/cryptopp/blob/master/ misc.h

    work page

  9. [9]

    GCC Documentation. [n. d.]. Options That Control Optimization. https://gcc.gnu.org/onlinedocs/gcc. Optimize-Options. html# Optimize-Options ([n. d.])

    work page

  10. [10]

    Vijay D’Silva, Mathias Payer, and Dawn Song. [n. d.]. The Correctness-Security Gap in Compiler Optimization. In 2015 IEEE Security and Privacy Workshops (2015-05). IEEE, 73–87. https://doi.org/10.1109/SPW.2015.33

    work page doi:10.1109/spw.2015.33 2015

  11. [11]

    Simon et al. [n. d.]. Constaint-time choose for Clang/LLVM. https://github.com/ lmrs2/ct_choose

    work page

  12. [12]

    Marc Joye and Sung-Ming Yen. 2002. The Montgomery powering ladder. InInter- national Workshop on Cryptographic Hardware and Embedded Systems . Springer, 291–302

    work page 2002

  13. [13]

    Libgcrypt. [n. d.]. bufhelp.h. https://github.com/gpg/libgcrypt/blob/master/ cipher/bufhelp.h

    work page

  14. [14]

    Libgcrypt. [n. d.]. Commit. https://github.com/gpg/libgcrypt/commit/ 168668228c7c49e70612cb4d602d6d603a2add2c

    work page

  15. [15]

    Libsodium. [n. d.]. utils.c. https://github.com/jedisct1/libsodium/blob/master/ src/libsodium/sodium/utils.c

    work page

  16. [16]

    lmrs2. [n. d.]. X86ZeroStackPass.cpp. https://github.com/lmrs2/ llvm/blob/cbc06dfbeffed5657185740d08c7ca8625326785/lib/Target/X86/ X86ZeroStackPass.cpp#L1188

    work page

  17. [17]

    Monocypher. [n. d.]. monocypher.c. https://github.com/LoupVaillant/ Monocypher/blob/master/src/monocypher.c

    work page

  18. [18]

    Monocypher. [n. d.]. Repository. https://github.com/LoupVaillant/Monocypher

    work page

  19. [19]

    OpenSSL. [n. d.]. OPENSSL_cleance. https://www.openssl.org/docs/man1.1.1/ man3/OPENSSL_cleanse.html. 8

    work page

  20. [20]

    Oscar Reparaz, Josep Balasch, and Ingrid Verbauwhede. [n. d.]. Dude, Is My Code Constant Time?. In Design, Automation & Test in Europe Conference & Exhibition (DATE), 2017 (2017-03). IEEE, 1697–1702. https://doi.org/10.23919/DATE.2017. 7927267

    work page doi:10.23919/date.2017 2017

  21. [21]

    Laurent Simon, David Chisnall, and Ross Anderson. [n. d.]. What You Get Is What You C: Controlling Side Effects in Mainstream C Compilers. In2018 IEEE European Symposium on Security and Privacy (EuroS&P) (2018-04). IEEE, 1–15. https://doi.org/10.1109/EuroSP.2018.00009

    work page doi:10.1109/eurosp.2018.00009 2018

  22. [22]

    Frans Kaashoek, and Armando Solar-Lezama

    Xi Wang, Nickolai Zeldovich, M. Frans Kaashoek, and Armando Solar-Lezama. [n. d.]. A Differential Approach to Undefined Behavior Detection. 59, 3 ([n. d.]), 99–106. https://doi.org/10.1145/2885256

    work page doi:10.1145/2885256

  23. [23]

    Zhaomo Yang, Brian Johannesmeyer, Anders Trier Olesen, Sorin Lerner, and Kirill Levchenko. [n. d.]. Dead Store Elimination (Still) Considered Harmful. ([n. d.]), 16. 9

    work page