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
>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 al
> 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
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
>con
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 th
