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
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.
Return to December 1995
Return to “lull@acm.org (John Lull)”