[Cryptography] Compiler optimization side channel

[Jerry Leichter]

> 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.

Yes, cryptographic code is important - but so are other things.  Most "sensitive" data spends most of its time *un*encrypted, being manipulated by all kinds of code which doesn't, and probably can't, worry about data remanence or side-channel leakage.

In one project I worked on a long time back, I actually implemented two C++ classes, RedString and BlackString.  A BlackString contained encrypted information; a RedString the result of decrypting a BlackString.  The destructor for a RedString wiped its memory - not perfectly, C++ being what it is, but it tried.  Keys, for example, had to be BlackString's - which happened automatically for almost all keys because they were decrypted from something using a key encryption key.  There were other restrictions to make it harder to "do the wrong thing"; e.g., the network communication primitives only accepted BlackString's.  Again, not perfect, but - maybe - better than nothing.  Did this *really* make the code more secure?  A little perhaps - probably more due to the disciplined way it made you think about the data you were working with.  But realistically there were way, way easier ways to attack the system than trying to pull temporary data from memory.

What's important is that there be *some* way to get the necessary primitives in a crypto library implemented.  It's likely not going to be portable, nor pretty.  But that shouldn't be surprising - there will always be some tiny core of a system that relies on very specific hardware properties, and it's going to require some kind of special coding tricks.

                                                        -- Jerry