This discussion is interesting, but only obliquely relevant to
firewalls. For those who are interested, it's being discussed with
much more expertise in sci.crypt where it belongs. If you'll take your
postulating there, you'll read followups by Paul Kocher, Ron Rivest,
Bruce Schneier, and others with a lot more expertise than you've found
here. And you'll clog up a lot fewer mailboxes.
- KH
----- Begin Included Message -----
From: mdr @
vodka .
sse .
att .
com
Subject: Re: Timing Attacks
To: fod @
brd .
ie (Frank O'Dwyer)
Date: Thu, 14 Dec 1995 08:51:22 -0500 (EST)
Cc: mdr @
vodka .
sse .
att .
com, PADGETT @
hobbes .
orl .
mmc .
com,
firewalls @
GreatCircle .
COM
Frank,
>
> >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.
>
> The problem is that this is only true if you manage not to
> affect anything else that is visible externally. For example,
> if you just called 'sleep()', then other processes may wake
> up. And if those processes were providing net services...
You, bring up a good point, but it sounds like the data rate would
definitely be far less under those conditions. Of course you could
implement a network interface with constant response per packet, but
that would slow the whole thing down to the worst case response time
of the encryption algorithm. I see two levels here:
1) could an attacker with access to the same box via a login
account infer the key by watching your process
communicate?
2) could an attacker with only a sniffer infer the key by
observation?
Scenario 2 is definitely the scary one, and the paper seems to imply
that it is possible to mount that attack. However, I gather that
stopping the attack may not be impossible or even all that dificult
(discussion above not withstanding) however it raises horrible
concerns for all of the encryption implemented so far that was put
inplace without the knowlege that such an attack was possible :(
If this attack is implementable, those existing systems are in big
trouble. Guess we'll have to wait for his full paper to hit the
web.
Mark
----- End Included Message -----
Follow-Ups:
|
|
