[Cryptography] Compiler optimization side channel
John Levine
johnl at iecc.com
Sat Aug 24 13:23:34 EDT 2024
It appears that Dave Horsfall <dave at horsfall.org> said:
>-=-=-=-=-=-
>
>On Fri, 23 Aug 2024, Phillip Hallam-Baker wrote:
>
>[...]
>
>> Which looked all well and good. But then I thought to myself, what if
>> the compiler gets hold of that data and decides to optimize the
>> arithmetic creating temporary variables that it leaves hanging about?
>
>This raises something that I've been thinking about for a while; having
>written your carefully-crafted code, why would anyone want an "optimiser"
>to get its paws on it?
It's more complicated than that. A common way for a compiler to generate code is to start
with an abstract machine with an unlimited number of registers, then use an optimizing
pass to map the abstract registers onto the fixed set of real ones. Without at least some
optimizing, you'd have stupendously awful code full of redundant moves and stores to
memory.
The goal of an optimizer is to transform the object code so that it is faster or smaller
and produces the same results as before. The problem is deciding what "same" means. In
early Fortran compilers, anything that was mathematically (not numerically) equivalent was
fair game so it turned A*B+C*B into (A+C)*B. These days optimizers tend to stick to
numerically equivalent results which is fine for most programs but not when there are side
effects not explicit in the code.
The C "volatile" qualifier prevents optimizing away variable references which look
redundant or dead, but aren't because something else might be looking at the variable,
often because it's an I/O device. There are side effects that most programs don't care
about but matter in crypto code, like leaving values in registers, or doing loops in
constant time.
The right solution is to make your language more expressive so you can say what you
mean, e.g., this value is sensitive so don't leave copies of it, this loop needs to
run in constant time so don't helpfully remove code that looks dead.
I'm not aware of anyone working on this. Is anyone else? I suppose I should ask
comp.compilers too.
R's,
John
More information about the cryptography
mailing list