Good points all.
I was implicitly assuming that d(k, x) is related to the timing of
f(k,x) -- tailored to the algorithm(s) used, and that the attacker
cannot control k. Actually the idea was to have k merely provide a
unique function d_k(x) for each host.
The only way to avoid this is to make
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
From: Travis H. [EMAIL PROTECTED]
Sent: Nov 16, 2005 11:37 PM
To: David Wagner [EMAIL PROTECTED]
Cc: cryptography@metzdowd.com
Subject: Re: timing attack countermeasures (nonrandom but unpredictable delays)
...
I don't follow; averaging allows one to remove random variables from
the overall time
Travis writes:
The naive countermeasure to timing attacks is to add a random delay,
but of course that can be averaged out by repeating the computation.
I have never heard anyone propose a delay that is based on the input,
and maybe some per-machine secret, so that it is unpredictable but
The naive countermeasure to timing attacks is to add a random delay,
but of course that can be averaged out by repeating the computation.
I have never heard anyone propose a delay that is based on the input,
and maybe some per-machine secret, so that it is unpredictable but
constant. Of course
