Re: /dev/random in 2.4.6

[Andreas Dilger <adilger@turbolinux.com>]

Steve Hill writes:
> On Wed, 15 Aug 2001, Richard B. Johnson wrote:
> > Same problem on 2.4.1. The first 512 bytes comes right away if
> > /dev/random hasn't been accessed since boot, then the rest trickles
> > a few words per second.
> 
> Hmm...  Well, ATM I've kludged a fix by using /dev/urandom instead, but
> it's not ideal because it's being used to generate cryptographic keys, and
> urandom isn't cryptographically secure.
> 
> I might have a look into increasing the size of the entropy pool so
> there's more data to access at once...

Yes, it is possible to increase the size of the in-kernel entropy pool
by changing the value in linux/drivers/char/random.c.  You will likely
also need to fix up the user-space scripts that save and restore the
entropy on shutdown/startup (they can check /proc/sys/kernel/random/poolsize,
if available, to see how many bytes to read/write).

> Are you seeing the problem on a normal machine? (I assumed I was seeing it
> because I'm using Cobalt hardware that's not going to get much entropy
> data due to the lack of keyboard, etc)...  although when I'm generating
> this data I'm using a root NFS filesystem, so there should be plenty of
> network interrupts happening,which should generate some entropy...

Note that network interrupts do NOT normally contribute to the entropy
pool.  This is because of the _very_theoretical_ possibility that an
attacker can "control" the network traffic to such a precise extent as
to flush or otherwise contaminate the entropy from the pool by sending
packets with very precise intervals and generating interrupts so exactly
as to fill the entropy pool with known data.  IMVHO, this is basically
impossible, as the attacker could not possibly control ALL of the network
traffic, and you could optionally define "safe" and "unsafe" interfaces
for terms of entropy.

It is basically inconcievable (IMHO) that anything but a machine connected
via a single crossover cable could "attack" a system precisely enough to
actually compromise the entropy pool because of network interrupts, but
then again people with more knowledge of this than I are in charge.

That said, if you are running on a machine with an Intel i81[05]
chipset, it has a hardware random number generator (I doubt Cobalt boxes
have these).  Alternately, you you need to add SA_SAMPLE_RANDOM to the
request_irq() call of the network card in your system.

You may also want to add a kernel/module parameter to make this flag
conditional on a per-controller basis, so for example it will only add
entropy from the internal interface of a firewall, and not the external
interface (if you have identical NICs on both).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert