It's my understanding that although a single item of timing data would
be useless, that given a sufficient number of instances the "random"
elements of the network could be statistically separated from the
constant difference in timing that a "bit" in the exponent can make.
Sounds kind of like the same type of technology applied to
spread-spectrum radio.
What I don't understand is why the threat could not be trivially
eliminated by waiting a fixed time interval for each response.
Although this would slow the response down to that of the worst case
performance of the algorithm, no data would be available external to
the host. This is not a fundamental weakness in RSA, rather it's a
weakness in an implementation that is leaking bits via a timing
channel. B2 and higher secure os's try to cut down on these covert
channels, but sometimes all you can do is reduce the bit rate. The
disturbing thing is that 40 bits or even 128 bits is very little data
and that even a single bit cuts brute force in half.
Of course, even it the above works, that doesn't mean that the above
has been implemented. To me this looks like a very disturbing attack.
The paper claims that as the algorithm progresses across the exponent
that it can detect "wrong turns" because no futher correllations can
be found along these dead ends. This raises the possibility that it
could be quite fast!
Mark Riggins
>
> Frank rites:
> >From the description, it sounds like all you need some "better than
> >random guess" at how long en/decryption takes. And that's certainly
> >possible without physical access. For example, if you view a
> >remote server as an en/decrypting 'black box' (among other things)
> >then you can give it work to do, and observe the response time.
>
> Can see how that might be possible at the keyboard. Might be possible on
> a remote terminal with a direct connection. Cannot see how it would work
> on a packet based network (having enough trouble with a std deviation of
> 188 usec against an average difference of 17 usec.), just too many random
> factors involved.
>
> Warmly,
> Padgett
>
>
References:
-
re: Timing Attacks
From: "A. Padgett Peterson, P.E. Information Security" <PADGETT @
hobbes .
orl .
mmc .
com>
|
|
