[Cryptography] Predictability for timing side-channel resistance

[Henry Baker]

I'm very much in favor of *timing predictability* as one component in defeating timing side-channels.

Presumably, the rationale is that a single piece of *software* can be *compiled* and run on many different architecture implementations *with "predictable timing"*.

If you think about this very much, you realize that the whole point of predictability is to enable a given piece of crypto (or privacy-sensitive) software which is timing-side-channel-resistant on one implementation will also be timing-side-channel-resistant on other implementations.

But then all compilers and all HW implementations must then forever be *lock-stepped* together, else we lose the efficiency of "code once", "run everywhere".  We could never improve the compiler or improve the hardware, without changing the timing and therefore losing *timing compatibility* with previous generations.

Perhaps a way out of this would be to decide on a given level of jitter, and then "strip" compile the software into a sequence of "more-or-less atomic sub-sequences", with *synchronization fences* between each two such sub-sequences.  These synchronization fences would *barrier synchronize* with a *real-time clock*.

Yes, the code would still execute slowly (albeit predictably), but slower code can also save on power!  :-)