[Cryptography] Compiler optimization side channel

[Ron Garret]

> On Aug 24, 2024, at 10:23 AM, John Levine <johnl at iecc.com> wrote:
> 
> 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.

Calling that code "stupendously awful" concedes too much.  It's only "stupendously awful" according to a quality metric that values speed over all else.  If you care about security, the "stupendously awful" code is the optimized version that runs fast but has exploitable vulnerabilities.

rg