[Cryptography] Compiler optimization side channel

[Christian Huitema]

On 8/24/2024 6:02 PM, Jerry Leichter wrote:
>> 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.
> I find it extremely unlikely that, even if someone is working on this, it will ever find its way into mainstream compilers.  The fact is, code for which this matters is *extremely* rare.  It's really hard to justify the additional complexity in the compiler and, perhaps, the language to support what probably amounts to, in the entire world, at most, a few hundred thousands of lines of code if you add up all the actually used implementations of cryptographic primitives - as against the many billions of lines for code for which this kind of consideration is completely meaningless.

Recent compilers do have pragma or attributes to ensure that a 
particular piece of code is not optimized. They implement it using code 
marking that tells the compiler to leave this segment as is. It is non 
standard, not defined in C (let alone C++) and so GCC, Clang and 
Microsoft all have different names for the macros or the attributes. It 
is also version dependent, in the sense that old compiler versions don't 
do that. But there are common traits, such as having the granularity at 
the function level, as in, "for this function, do not optimize".

Which makes me think that it should be possible to standardize the 
feature in a future version of C. But I have no idea what kind of 
lobbying is required to achieve that.

But then, C is of course yesterday's problem. The new code tend to be 
written in Rust, and I have no idea how Rust support constant time 
execution.

-- Christian Huitema