  The constant-time property is considered the security standard for
cryptographic code. Code following the constant-time discipline is free from
secret-dependent branches and memory accesses, and thus avoids leaking secrets
through cache and timing side-channels. The constant-time property makes a
number of implicit assumptions that are fundamentally at odds with the reality
of cryptographic code. Constant-time is not robust. The first issue with
constant-time is that it is a whole-program property: It relies on the entirety
of the code base being constant-time. But, cryptographic developers do not
generally write whole programs; rather, they provide libraries and specific
algorithms for other application developers to use. As such, developers of
security libraries must maintain their security guarantees even when their code
is operating within (potentially untrusted) application contexts. Constant-time
requires memory safety. The whole-program nature of constant-time also leads to
a second issue: constant-time requires memory safety of all the running code.
Any memory safety bugs, whether in the library or the application, will wend
their way back to side-channel leaks of secrets if not direct disclosure. And
although cryptographic libraries should (and are) written to be memory-safe, it
is unfortunately unrealistic to expect the same from every application that
uses each library. We formalize robust constant-time and build a RobustIsoCrypt
compiler that transforms the library code and protects the secrets even when
they are linked with untrusted code. Our evaluation with SUPERCOP benchmarking
framework shows that the performance overhead is less than five percent on
average.
