> On Aug 16, 2023, at 3:53 AM, Alexander Monakov <amona...@ispras.ru> wrote:
>
>> ...
>> Is "timing-safety" a security property? Not the way I understand that
>> term. It sounds like another way to say that the code meets real time
>> constraints or requirements.
>
> I meant in the sense of not admitting timing attacks:
> https://en.wikipedia.org/wiki/Timing_attack
>
>> No, compilers don't help with that (at least C doesn't -- Ada might be
>> better here but I don't know enough). For sufficiently strict
>> requirements you'd have to examine both the generated machine code and
>> understand, in gruesome detail, what the timing behaviors of the executing
>> hardware are. Good luck if it's a modern billion-transistor machine.
>
> Yes. On the other hand, the reality in the FOSS ecosystem is that
> cryptographic libraries heavily lean on the ability to express
> a constant-time algorithm in C and get machine code that is actually
> constant-time. There's a bit of a conflict here between what we
> can promise and what people might expect of GCC, and it seems
> relevant when discussing what goes into the Security Policy.
I agree. What should be said is that such techniques are erroneous. The kind
of code you're talking about inserts steps not strictly needed for the
calculation to make it constant time (or more nearly so). But clearly that has
to rely on an assumption that the optimizer isn't smart enough to spot those
unnecessary operations and delete them. Never mind the fact that it relies on
a notion that C statements have timing properties in the first place, which the
standard doesn't do.
So I would argue that a serious attempt to cure timing attacks has to be coded
in assembly language. Even then, of course, optimizations in modern machine
pipelines may give you trouble, but at least in that case you're writing
explicitly for a specific ISA and are in a position to take into account its
timing properties, to the extent they are known and defined.
paul
