1995-12-12 - Re: Timing Attacks

Header Data

From: lull@acm.org (John Lull)
To: cypherpunks@toad.com
Message Hash: 57af23c79a6d0cb596b450bd894825e54d417c41f5d3aa2535aba9e34169db32
Message ID: <30cd30bd.1863868@smtp.ix.netcom.com>
Reply To: <9512112205.AA07602@toad.com>
UTC Datetime: 1995-12-12 08:56:56 UTC
Raw Date: Tue, 12 Dec 1995 16:56:56 +0800

Raw message

From: lull@acm.org (John Lull)
Date: Tue, 12 Dec 1995 16:56:56 +0800
To: cypherpunks@toad.com
Subject: Re: Timing Attacks
In-Reply-To: <9512112205.AA07602@toad.com>
Message-ID: <30cd30bd.1863868@smtp.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


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.





Thread