I guess people are just going to keep discovering that you can't really make a C compiler do constant time
https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
10
Discussion
Loading...
@regehr this is so funny. there is like, a whole field of study around this and its potential countermeasures, and at least one PhD
@regehr "The user types in a password, which gets checked against a database, character by character"
Seriously? That is how they think it works?
@regehr yes you can, unless you care about correct results too.
@regehr Maybe it's time to write new assemblers that complement NASM*.
* Or MASM; I wish NASM had an invoke keyword, like MASM, to abstract away calling conventions. Rather than writing a macro for it.
@regehr all I will say to that is eyup
1
@kaoudis I've not been paying too much attention to the LLVM effort-- anything interesting going on there? or should I just dig into the discourse?
1
@regehr I think* @wizardengineer landed the first bits of that work!
*I left trail of bits voluntarily (and for reasons unrelated) a bit before this happened though
@regehr
> make a C compiler do constant time
something something "state of sin".
( Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin. John von Neumann, "Various techniques used in connection with random digits" by John von Neumann in Monte Carlo Method (1951), ed. A.S. Householder, G.E. Forsythe, and H.H. )
@regehr omg that headline
1
@secretasianman it's really bad
@regehr I would be interested to see the same article focused on CompCert instead. Otherwise, cryptographers might need to... roll their own assembly? Crazy idea in 2026 if true
1
@ashguy CompCert absolutely makes no promises about this, and (in most cases) neither does the hardware -- which absolutely matters
people who care about this need to work in actual solutions, not faith-based efforts like obfuscating the code
1
"Can it be fair to require the average programmer to understand inline assembly, or any of these other inherently obtuse obfuscation techniques?"
can it be fair for the average programmer (if they don't understand this stuff) to just not write code where timing channels matter? who even writes these articles
4
@regehr I think it's reasonable to want portable ways (preferably even beyond one ISA!) to write constant time code, but yeah, the average programmer should mostly be admitting they don't know what they're doing and not proceeding to ask an LLM
1
@flippac I agree, it's fine to want better solutions! these just aren't going to look like C code
@regehr @rachelplusplus I'm sure willing to believe that some hypothetical value range optimizer could thwart the constant time intentions of NetBSD's C implementation of consttime_memequal ... but they don't seem to, yet. https://github.com/NetBSD/src/blob/39dd19e8665573fca8f6443bf8093ffb05643ca8/common/lib/libc/string/consttime_memequal.c
I think the presentation maybe ignored that who knows whether a == b is constant-time, too. And heck I know about the |= a ^ b trick but not that !ret might not be constant-time on some platform worth worrying about; I only thought about the constant-time-ness of a == b ...
bool equal(int a, int b) { return a == b; }
in fact this is a non-constant-time function on avr-gcc (15.2.0) -Os, womp-womp.
I also noticed while playing with godbolt that -O3-optimized code got complex enough that I might easily overlook some branch that turned out to be not constant-time.
@regehr What about fractions?
@regehr I would certainly hope that the "average programmer" is not futzing around in constant-time-requirement crypto kernels.
That said, this kind of thing is a real issue, not just for crypto code, and the usual responses are extremely Not Helping. For a less security-critical very recent example, see for example this https://mastodon.gamedev.place/@zeux/116038414798979026 yesterday.
2
@rygorous sure, and the right answer is to figure out real solutions (as seems to be happening in LLVM, for constant time), not complaining about the optimizer
1
@regehr Without getting too much into the weeds on that particular point here, let's just say that you can certainly report problems but that sometimes takes a very long time to resolve and doesn't exactly help when you need a solution to ship today.
It also gets especially stupid sometimes when other hot-topic issues get into the crossfire.
@regehr There's a very real tension between the "the compiler always knows best" attitude and the preponderance and general frustrating-ness of cases where you write something in a system-level lang that would be just fine with a pretty literal 1:1 translation (up to register allocation) and the compiler just makes a complete mess of it.
1
@regehr
Especially when you get a glib reply along the lines of "just use assembly if the compiler doesn't do what you want". As someone who actually ships ASM, it's Not That Easy.
1
@regehr Just a few of the fun things I've run into:
1. not all compilers you support might even have inline ASM (*cough* MSVC *cough*)
2. when they do, they might not actually agree on the dialect of inline ASM. There's many fun sharp edges with differences between say Clang and GCC once you get into things like constraint modifiers on some archs.
3. when you work through that, there are also (not surprisingly) rough edges in the transition areas between inline ASM and regular code.
1
@regehr all of which add up to "you might end up needing to write a lot more ASM than you thought if you want your loop to do what you want".
Which then hurts you in other ways; for example, with untrusted data processing, you absolutely want access to things like ASan and UBSan and libfuzzer and the like, and none of the instrumentation works in inline ASM (not surprisingly), making code _way_ less testable, which sucks because the stuff you do this with is usually workhorse kernels.
1
1+ more replies (not shown)
@regehr Do you think it would be possible to make a special-purpose optimization mode that only makes changes which are "safe" for cryptographic code? Or is that too underspecified/hard of a problem?
1
@rachelplusplus there's some work in this direction in the LLVM community!
https://discourse.llvm.org/t/rfc-constant-time-coding-support/87781