[Cryptography] Compiler optimization side channel

[Bertrand Mollinier Toublet]

> On Aug 25, 2024, at 8:15 AM, Christian Huitema <huitema at huitema.net> wrote:
> 
> 
> 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.
> 
Even if we focus on “the past” (C), whether the compiler itself optimizes or not hardly addresses the issues around, particularly, “cleaning up key material” on general purpose processors, doesn’t it?

At execution time, the hardware itself may leave traces of a given piece of data in various places, including caches and, potentially, registers and there is no option in the code to express how *that* should be handled. As a witness to the magnitude of that problem is the large body of active research on cross-VM side channel attacks.

In other words: the compiler is not the solution, either.
--  
Bertrand