[5132] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: depleting the random number generator

daemon@ATHENA.MIT.EDU (Mike Brodhead)
Sun Jul 18 06:27:23 1999

Reply-To: mkb@black-ice.org
To: John Denker <jsd@research.att.com>
Cc: cryptography@c2.net
In-Reply-To: Your message of "Sat, 17 Jul 1999 16:45:34 -0400."
             <4.1.19990717161153.00ad0850@surfcity.research.att.com> 
Date: Sat, 17 Jul 1999 22:04:05 -0700
From: Mike Brodhead <mkb@black-ice.org>

> Step 3a) If Whitney is getting key material from /dev/random, the result is 
> a denial of service.  All the IPsec tunnels will time out and will be 
> replaced slowly or not at all, because of the entropy shortage.

seems to me that the reason the denial of service attack works does
not have anything to do with the randomness per se.  the attack works
because the host must expend a lot of time and/or CPU juice before the
new connection is determined to be bogus.

the more CPU intensive the authentication, the greater the risk.  you
can mitigate this by finding low-CPU ways of denying some connections
before doing a lot of number crunching.  for starters, get a good
firewall in place.  if your network is large (the domain "att.com"
leads me to believe it is :), then some internal firewalling might be
in order.  if you can weed out attackers based on some simple criteria
(like IP address) first, you have reduced your risk quite a bit.

if you want to get fancy, the firewall machine can take note when a
large number of connections originates from a particular source and
shut down all access from that source.

--mkb

-------------------------------
Michael Kennedy Brodhead
Security - Design - Development
<mkb@black-ice.org>




home help back first fref pref prev next nref lref last post