[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Timing Attacks
> From: "Rev. Ben" <[email protected]>
>
> I'm not so sure I see the great usefulness of this attack.
>
> I've taken a cursory glance at Mr. Kocher's paper on-line and what it
> comes down to essentially, if I undestand it correctly, is that you need
> to be as sure of the timing as you can be.
>
> Now, on a distributed system, you can't measure those timings, because
> any latency could come from the originating computer, the links in the
> middle or any combination of them.
But, what if one of the computers is connected on a "hostile" lan.
For example - your typical student PC running in a grad-student office
or on the network in the dorms. Sniffing packets from it shouldn't be
too hard (yes, good ethernet concentrators make it harder - but not
impossible). These packets will give you the necessary timing information.
> Also precise timings can be limited by fluctuating load averages amongst
> other things in a time-sharing computing environment. While this might
> work in a lab, with the current advances in computing speed, the
> differences between a fast and a slow calculation can easily be opaqued
> by network lag.
>
> Am I missing something, or does this attack only work in a lab?
What if that is a PC running Windoze or single-user Linux? Then there
aren't likely to be fluctuating load averages. The advesary is
close to the one end, and away you go......
Of course, targeting a server is much more pratical in terms of what
you may gain access to. Several congested network hops will generate
lots of delays, BUT what about the 4:00am hit from the dialup terminal
servers that happen to be on the same ethernet as the secure server.
This would be a normal situation for many ISPs.
All of that said - I think that this is more pratical in the "lab"
than on the net. But, it is a very clever approach to the
problem of cracking a crypto system. It serves us all a good example
that we need to leave NO stone unturned when examining a system.
Dan
------------------------------------------------------------------
Dan Oelke Alcatel Network Systems
[email protected] Richardson, TX