Re: Timing Attacks

samman-ben@CS.YALE.EDU writes:
>I'm not so sure I see the great usefulness of this attack.

It appears to be more practical than 99 percent of the "weaknesses"
that get published.  Not bad, I'd say.  It's also a very cute attack;
I'd never have guessed a priori that you could get that many key bits
from timing data.

>work in a lab, with the current advances in computing speed, the 
>differences between a fast and a slow calculation can easily be opaqued 
>by network lag.

"Random delays added to the processing time may increase the number of
ciphertexts required, but do not completely solve the problem since
attackers can compensate for the delay by collecting more
measurements.  (If enough random noise is added, the attack can
become infeasible.)"  [extended abstract, p. 5]

Sufficient network noise *might* make the problem go away, in some
cases, but that's a weak sort of claim to make about a cryptosystem.
(What if the attacker tries at six in the morning, or cracks a machine
local to you, or just gets lucky?)  You might put your server behind a
time-quantizing firewall...

Also, it's not just networked machines.  Smart cards may have a hard
time defending themselves against hostile card readers.  They're slow
already; the user may not appreciate the extra time spent for
obfuscation.  (This depends critically on the numbers, of course.)

--
   Eli Brandt
   eli+@cs.cmu.edu

On Mon, 11 Dec 1995 17:04:56 -0500 (EST), Eli Brandt wrote:

> Also, it's not just networked machines.  Smart cards may have a hard
> time defending themselves against hostile card readers.  They're slow
> already; the user may not appreciate the extra time spent for
> obfuscation.  (This depends critically on the numbers, of course.)

Smart card have one major advantage, though.  During these types of
operations, a smart card will be totally dedicated to the crypto.
Calculating the maximum possible delay for a given key size should be
relatively easy.

Most single-chip micros also have a timer that could be readily
dedicated to counting out this maximum possible delay, and the result
held only that long.  This could, on an 8051 (as a fairly typical
example) be easily controlled (with a 1-instruction loop) to within 2
instruction cycles.  Given another dozen or so instructions, it can be
controlled to a single fixed delay.

Where minimum and maximum delays only differ by 1% or so for a given
key size, no one will ever notice the extra time required to hold the
result for the maximum possible delay.