[Cryptography] Defeating timing attacks

[John Denker]

On 07/12/2017 12:28 PM, Ray Dillinger wrote:

> The issues with trusting electronic hardware have become so intractable
> that for some applications it seems that building mechanical cipher
> hardware should be reevaluated.
> 
> No, I am not joking.  

That's not practical.  Better solutions are readily available, as
discussed below.

On 07/14/2017 04:14 PM, Tom Mitchell wrote:

[...]
> so it triggers unpredictably.

Not good enough.

[...]
> to obfuscate the timing of the interesting task.

Not good enough.

[...]
> All the things system benchmark engineers try to control to get the
> best possible
> reproducible benchmark results gives hints for things to upset the system and
> make timing locally and remotely difficult.

Not good enough.

Randomizing the timing just turns the attack into a statistics
problem.  The NSA is reeeeeally good at statistics.  You can
"somewhat" slow down the leak, but it's still a leak.

Furthermore, a much better way to defeat timing attacks is already
known:
 a) use a dedicated machine,
 b) inside a Faraday cage, and
 c) emit the results at some pre-arranged time.

That's because
 a) in a multi-tasking environment, one task can spy on another
 b) timing isn't the only issue;  there are other side-channels
 c) you don't need to defeat the timing attack on an instruction-
  by-instruction basis, just on a message-by-message basis.

Things get a little trickier in interactive situations (as opposed
to file-sized messages) but still manageable.

This approach means you don't need to argue with the hardware
designers and compiler designers.  They do their thing, and you
do yours.

As will all of cryptography, and security in general, this still
requires tremendous attention to detail.  There is a rather long
list of ways bad guys could exfiltrate information about your
message, and you have to stop them all.  Even so, the point
remains, the timing issue is manageable.