Re: Random delay as a countermeasure to timing attacks

Francois Grieu <fgrieu@xxxxxxxxx> writes:

In article <einqr9$i6t$2@xxxxxxxxxxxxxxxxxxxxxx>,
Unruh <unruh-spam@xxxxxxxxxxxxxx> wrote:

One of the key features of an algorithm are that it be fast.
So you want to slow it down. And you need to slow it down by
much more than the slowest part, so that your random slowdown
can swamp the significant difference between the fastest and
slowest runs.

I want to slow it down by a time that hides the timing
VARIATION on the algorithm due to the effect (e.g. cache
misses) exploited by my adversary. This might still
be low compared to the total time, and the cost of using
alternatives to table-lookup, e.g. boolean functions
equivalent to the tables.

It might be. Ie, you have to slow it down by many times the variance ( or
perhaps the worst case minus the best case) in order to hide the difference
in timing. And I think with most systems, that difference will be of the
same order as the time of the algorithm.

If it is much smaller (what in the world is the algorithm spending all its
time on?) then you may be able to do it your way, I agree.

François Grieu

Relevant Pages