Constant-time support lands in LLVM: Protecting cryptographic code at the compiler level
85 points by sknebel
85 points by sknebel
It looks like the author has changed the title and the link: https://blog.trailofbits.com/2025/11/25/constant-time-support-coming-to-llvm-protecting-cryptographic-code-at-the-compiler-level/
Now "coming to" rather than "lands in" LLVM.
My theory why the post was removed: It’s incomplete and looks a bit drafty. For example, it does actually not link to any changes that have landed in LLVM, and indeed most of the PRs are still open: https://github.com/llvm/llvm-project/pulls?q=author%3Awizardengineer+is%3Apr
That kind of contradicts the title of the post.
So, benign reading: someone hit the publish button by accident. That also explains why they changed the slug without redirect and de-published the post.
Neat. Pleasing to see this was based on a paper by @david_chisnall, Laurent Simon, and Ross Anderson from 2018. (The paper also discusses secure erasure, but it seems that explicit_bzero() / memset_explicit() are still just library functions, and compiler developers have not yet been persuaded it needs a builtin.)
I’m curious what kind of string operations they have in mind for future work.
And I would have thought that general constant-time expressions need more annotation than just a wrapper. Apart from control flow, the other non-constant-time operation is accessing memory. If an expression is constant time there must be tight control over how it accesses memory, which typically means that addresses don’t depend on any secret values. (So, not actually constant time, just avoiding a side-channel that leaks secrets.) I suppose a simple but useful possibility might be to ensure that array indexes are statically known, assuming that array base addresses are not secret.
This is great! When I learned about side channel attacks and constant time operations, I was quite surprised to find out that many cryptographic implementations rely on essentially hoping that the compiler doesn't mess up constant timeness of bit-masking operations combined with optimization barriers like volatile reads (e.g. the commonly used rust crate subtle does this).
There is still the problem that on x86-64 you don't actually have constant time instructions, because the CPU is still vulnerable to Hertzbleed, and leaks frequency and other scheduling information even if your code takes a constant number of cycles.
In the latest 2025 paper on https://www.hertzbleed.com/ they use Intel Thread Director to leak information about what the other CPU is doing. They demonstrate remotely leaking keys from a "constant-time" crypto implementation. (iIUC disabling frequency scaling is no longer an effective mitigation against this) The CPU vendors don't seem to be interested in fixing the problem, moving the responsability to software mitigations. (There isn't anything that a hypervisor or kernel could do to mitigate these AFAIK, all crypto code must take this into consideration) https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/frequency-throttling-side-channel-guidance.html
Of course constant time crypto is better than not, but you still need to implement mitigations like masking with a random key (RSA blinding) to avoid Hertzbleed. And if you do that you don't have to rely on constant time so much.
Trail of Bits always delivers imo.
Especially nice to see them continue to turn DARPA funding into ecosystem-wide security benefits
Wow, finally!! Nice.
Since i386 lacks cmov,
"i586" certainly doesn't.. I vividly remember installing Debian from a "more modern" laptop onto a disk intended for a VIA machine (for reasons), and said machine being unable to boot due to missing cmov! Downgrading to an "i486" kernel fixed it.
That's interesting, cmov was introduced in the P6-based Pentium Pro a.k.a. i686... so it's weird that a i586 kernel would require it.
Nice! hopefully GCC picks this up at some point.