1995-12-12 - Re: Timing Attacks

Header Data

From: eli+@GS160.SP.CS.CMU.EDU
To: cypherpunks@toad.com
Message Hash: 6ba9f0e13161e4c39114c549b1065eb1c5510973b63c0768b1d032becc424c82
Message ID: <9512112205.AA07602@toad.com>
Reply To: <+cmu.andrew.internet.cypherpunks+Qkn8QTu00UfAE0yrN:@andrew.cmu.edu>
UTC Datetime: 1995-12-12 06:16:14 UTC
Raw Date: Tue, 12 Dec 1995 14:16:14 +0800

Raw message

From: eli+@GS160.SP.CS.CMU.EDU
Date: Tue, 12 Dec 1995 14:16:14 +0800
To: cypherpunks@toad.com
Subject: Re: Timing Attacks
In-Reply-To: <+cmu.andrew.internet.cypherpunks+Qkn8QTu00UfAE0yrN:@andrew.cmu.edu>
Message-ID: <9512112205.AA07602@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


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






Thread