[Cryptography] [FORGED] Attackers will always win, and it's getting worse!

Arnold Reinhold agr at me.com
Thu Jul 13 21:54:29 EDT 2017


On Wed, 12 Jul 2017 17:34 Jerry Leichter asked:

> If the *hardware* won't guarantee anything about instruction execution time ... what [can] the compiler possibly do?  Do you assume a compiler that targets a particular exact mask and microcode level of a particular chip?

It’s possible to measure and characterize the instruction timings of specific processors. A compiler could take advantage of that data, which might be more trustworthy than manufacturer’s specifications anyway. At the least it’s worth finding out if there is, in practice, significant variation based on "particular exact mask and microcode level.”  But if it really is a problem that affects side channel security, then yes, it may be necessary to test incoming batches of microprocessors and customize code for them. I doubt it would come to that, but this sort of tight product control is not uncommon is product engineering. More likely security product manufacturers would select processor vendors who did not allow such extreme variation.  

For software intended to work on whatever is out there, including a timing test at startup that selects one of several implementations might cover most cases. For timings that are outside some acceptable range one might issue a warning issue a warning or refuse a secure connection, if that’s what it takes. There may also be other tricks that the compiler could do, such as inserting no-ops to make instruction timing more consistent. 

There are other problem areas where crypto-friendly compilers might help, such as insuring sensitive data is zeroed as soon as possible and never written to shared memories.  But at the very least, having some way to insure that compilers do not rearrange security critical code is just engineering common sense.

Arnold Reinhold


More information about the cryptography mailing list