Re: use of add_interrupt_randomness in drivers missing in many drivers

From: Sandy Harris (sandy@storm.ca)
Date: Wed Oct 18 2000 - 11:49:11 EST


Jeff Garzik wrote:
>
> "Oliver M . Bolzer" wrote:
> >
> > Hi!
> >
> > Recently I needed a lot of entroy for cryptographic purposes on a
> > server and took a look at where the entroy for drivers/char/random.c
> > was coming from, as the server didn't have any activly used mouse/keyboard.
> >
> > Anyway, I noticed that only 3 drivers were using add_interrupt_randomness()
> > to donate their irq timings into the entropy pool. Shouldn't other drivers
> > (especially network drivers) do this too ?
> >
> > The only thing needed is to add the SA_SAMPLE_RANDOM flag to request_irq
> > in the drivers.
> >
> > If nobody objects, I'll submit a patch that adds this to network drivers.
>
> Then you make your local random pool vulnerable to external
> manipulation, to a certain extent...

The question is to what extent.

On a server that does crypto, especially a FreeS/WAN IPSEC gateway
but also a web server doing lots of SSL or a mail server doing secure
sendmail or ..., you need secure random numbers and you may not have
keyboard or mouse activity. On a web or mail server, there's disk
activity, but on an IPSEC gateway you may not even have that.

In one previous discussion of this, I took implementer's estimates
of FreeS/WAN's randomness usage, did some arithmetic, and showed that
if we could get one bit of randomness per packet passing through, and
had a large enough pool to buffer out the supply/demand irregularities,
we were covered.

So methinks the questions are whether /dev/random can get one bit of
unknowable-by-the-enemy entropy per packet passing through a gateway
and whether it would estimate entropy sufficiently conservatively in
this case. If both answers are yes, please apply the patch.

You could buy Intel 810 or later chipset motherboards for all such
servers and use Jeff's driver feeding onto /dev/random. That's what
I'd do for a prodution server on a sensible budget, after auditing
the driver. You could also use some other hardware RNG, or just
hash microphone inputs and drop the results into /dev/random. That's
what I'd do on a pinched budget.

I'd still like to see the patch applied, though. I'd like /dev/random
to work well "out of the box" on the FreeS/WAN gateways people are
building out of older surplus hardware.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:13 EST