1995-12-14 - Re: Timing RSA and Certificates worth ??

Header Data

From: Bill Stewart <stewarts@ix.netcom.com>
To: lyalc@mail.mpx.com.au (lyal collins)
Message Hash: 42c79ecea1436dd9d95ae9da7d1e8ce8bbed33b658caa60f417bb8eae3e3f238
Message ID: <199512130721.XAA21701@ix7.ix.netcom.com>
Reply To: N/A
UTC Datetime: 1995-12-14 16:21:58 UTC
Raw Date: Fri, 15 Dec 1995 00:21:58 +0800

Raw message

From: Bill Stewart <stewarts@ix.netcom.com>
Date: Fri, 15 Dec 1995 00:21:58 +0800
To: lyalc@mail.mpx.com.au (lyal collins)
Subject: Re: Timing RSA and Certificates worth ??
Message-ID: <199512130721.XAA21701@ix7.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


At 12:50 PM 12/13/95 +1100, lyalc@mail.mpx.com.au (lyal collins) wrote:
>I meant that on-line certificate issuing, notary and similar services where
>data is submitted to a system for processing/RSA encryption are subject to
>this for of attack.
>Parts of the SEPP/STT protocols appear to require this of merchants and
>customers.
>I retract my comments about ecash/echeques - I'm not sure of the
>implications there yet.
>As for SEPP/STT - another nail in the coffin, me thinks.

For large environments like this, it's possible to work around the attack
by methods like queueing up all the signature jobs and doing them
serially; this makes it difficult for the Bad Guy to know whether the server 
is taking time doing his multiplications or Alice's or N other customers',
so he can't control timing very well by picking otherwise-informative numbers.

On the other hand, your smartcard or PC is still at risk, since it's _not_
doing a lot of them, unless it's doing them just sort of at random when
it's got nothing better to do and throws the real work in the middle.
#--
#				Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com
# Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281






Thread