timing attack countermeasures (nonrandom but unpredictable delays)

[Travis H.]

> In many cases, the observed time depends both on the input and on some
> other random noise.  In such cases, averaging attacks that use the same
> input over and over again will continue to work, despite the use of
> a pseudorandom input-dependent delay.  For instance, think of a timing
> attack on AES, where the time compute the map X |--> AES(K,X) depends only
> on K and X, but where the measured time depends on the computation time
> (which might be a deterministic function of K and X) plus the network
> latency (which is random).  Indeed, in this example even the computation
> time might not be a deterministic function of K and X: it might depend
> on the state of the cache, which might have some random component.

I don't follow; averaging allows one to remove random variables from
the overall time, but you're still left with the real computation time
plus the the deterministic delay I suggested as a function of the
input.

Specifically, time t(k,x) = f(k,x) + d(k,x) + r

Where r is a random variable modelling all random factors, f is the
time to compute the function, and d is the deterministic delay I
suggested that is a function of the inputs.  Averaging with repeated
evaluations of the same k and x allows one to compute the mean value
of r, and the sum f+d, but I don't see how that helps one seperate f
from d.  What am I missing?
--
http://www.lightconsulting.com/~travis/  -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com