From: droelke@rdxsunhost.aud.alcatel.com (Daniel R. Oelke)
Date: Thu, 14 Dec 1995 12:51:43 +0800
To: cypherpunks@toad.com
Subject: Re: Timing Attacks
Message-ID: <9512120216.AA03191@spirit.aud.alcatel.com>
MIME-Version: 1.0
Content-Type: text/plain



> From: "Rev. Ben" <samman-ben@CS.YALE.EDU>
> 
> 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
droelke@aud.alcatel.com                             Richardson, TX