Re: timing attacks.

New Message Reply About this list Date view Thread view Subject view Author view

Mike Rosing (eresrch@msn.fullfeed.com)
Thu, 25 Jun 1998 08:09:17 -0500 (CDT)


On Wed, 24 Jun 1998, burt rosenberg wrote:

>
> say we do:
>
> t1 = multiply( s, s ) ; // the square
> t2 = multiply( s, y ) ; // the multiply, just in case
> if ( bit(i,x) ) s = t2 ;
> else s = t1 ;
>
> to keep the times for one stage the same, but s is now
> either y*s*s or s*s, and it is possible that in the next
> stage (y*s*s)^2 gives a different timing than (s*s)^2.

So fix the multiply function to always take the same time
no matter what it's inputs are. Fix the exponential function
to do a "dummy multiply" which could be a whole bunch of
nops. The end result is *exactly* the same time of execution
no matter what the inputs are. That has to be slower than
anything else because it will obviously cover the longest time
case.

>
> actually, this is covered in a parenthetical remark in the
> orig. paper. even w/ this care, it cannot be said that
> timing{y^x} is not a function of x, hence can possibly
> be leaking info. about x.

The whole thing seems pretty trivial to me. Maybe it's becuase I do
timing with microcontrollers and matching code sections to have the same
run time is everyday practice. Doing it with a multiply ought to be
easier than doing it for a motor.

Patience, persistence, truth,
Dr. mike


New Message Reply About this list Date view Thread view Subject view Author view

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:19:04 ADT