Re: Random delay as a countermeasure to timing attacks
- From: run_signature_script_for_my_email@xxxxxxxxxxx (laura fairhead)
- Date: Mon, 06 Nov 2006 19:50:54 GMT
On Mon, 06 Nov 2006 18:04:28 +0100, Francois Grieu <fgrieu@xxxxxxxxx> wrote:
In article <BqJ3h.13$jb3.1@xxxxxxxxxxxx>,
Peter Pearson <ppearson@xxxxxxxxxxxxxxx> wrote:
On Mon, 06 Nov 2006 14:21:19 +0100, Francois Grieu <fgrieu@xxxxxxxxx> wrote:
[snip]
[to back this conjecture, I rely of the fact that the
weighted sum of n measurements with sum of absolute
values of coefficients normalized to 1 has a standard
deviation at least equal to that of the average of the
n measurements]
Huh? If each of the n measurements is always 100, then
the standard deviation of any weighted sum is zero,
while the average can easily be greater than zero.
But the standard deviation of the average is zero, too.
Maybe a wording problem with my use of "that"; I meant:
Standard dev of Sum(tj.wj) >= Standard dev of Sum(tj/n)
when the n fixed weights wj are such that Sum(|wj|)=1.
If we use a uniformly distributed random delay, the best
estimate of measurements of the SAME actual duration is
not based on the average of all the experiments (the average
of the extremes is better); is it a good reason to use another
distribution? which distribution?
is it enough to sum two uniform delays each half as long?
These are interesting questions you're asking, and I hope
somebody smarter than me will come along and answer them.
Meanwhile, it might help to simplify or clarify the goal.
Can we say that the attacker is trying to decide, with some
specified level of confidence, whether he's seeing values
from the population
1 + additive_noise_of_known_distribution
or the population
0 + additive_noise_of_known_distribution
?
Answering this question indeed has direct interest, as it
is relevant to a simplified timing attack, e.g. when the
adversary is trying to time strcmp(password,input) to
determine if she guessed the first byte of password right.
Hi Francois,
For say a log-in program, instead of muddling around with adding
random noise in the timing it would be sufficient to simply
initiate a system timer (alarm) at the begining and wait for
it to time out before finishing, whether successful or not.
This is also useful to help slow (single connection) brute
force attacks if you put the timer at say a cumbersome 3 second
delay.
Not sure but IIRC this is what linux login does already.
This way is also much simpler because there is no window
for attack at all and it involves the application of only
one simple method in all cases (fixed time execution, time T=f(E)
chosen for routine E which is at least suitably larger than the
maximum time for the routine to run).
regards
l
Unfortunately, the adversary performing a timing attack
against a crypto algorithm really makes something more
complex, like timing n different encryptions with additive
noise, and finding which hypothesis on key best fits her
measurements, maybe using an efficient technique such as
hillclimbing.
François Grieu
--
echo alru_aafriehdah@xxxxxxxxxx |sed 's/\(.\)\(.\)/\2\1/g'
.
- Follow-Ups:
- Re: Random delay as a countermeasure to timing attacks
- From: François Grieu
- Re: Random delay as a countermeasure to timing attacks
- References:
- Random delay as a countermeasure to timing attacks
- From: Francois Grieu
- Re: Random delay as a countermeasure to timing attacks
- From: Peter Pearson
- Re: Random delay as a countermeasure to timing attacks
- From: Francois Grieu
- Random delay as a countermeasure to timing attacks
- Prev by Date: Re: Chaum's punchscan
- Next by Date: Re: Chaum's punchscan
- Previous by thread: Re: Random delay as a countermeasure to timing attacks
- Next by thread: Re: Random delay as a countermeasure to timing attacks
- Index(es):
Relevant Pages
|
