/dev/random for FreeBSD [was: Re: /dev/random for Linux]

[Mark Murray]

>    Date: Mon, 30 Oct 1995 20:16:24 +0200
>    From: Mark Murray <mark at grondar.za>
> 
>    A colleague drew my attention to this, and I was so pleased with it that
>    I ported it to FreeBSD.
> 
> Which version did you grab?  More recent versions of the driver use a
> more efficient mixing algorithm suggested by Colin Plum.  There's also
> the beginnings of support for user-mode deamons to add randomness into
> the random pool by writing to /dev/random.  I also added support for
> reading the instruction timing register for x86 platforms that support
> it. 

Version 0.92 21st Sept 1995.

Something I didn't mention earlier; we felt that letting the unwashed
masses read /dev/*random was not a good idea, as they could deplete
the pool of entropy all to easily for attack purposes. For the same
(or similar) reason, giving the said unwashed masses _write_ privelige
might allow them to set /dev/*random to a known state. You've probably
already thought of this, but I just had to say it :-).

>    2) We felt that hooking all interrupts might be dangerous. IDE drives can
>    interrupt at a heck of a rate, and so can some serial ports, and we felt
>    that in these cases _not_ using the interrupt was a good idea. So I
>    added an ioctl to allow the superuser to select his own set, appropriate
>    to the hardware in use. It is nearly impossible to do this automatically.
> 
> Indeed; I can't emphasize this enough.  The clock interrupt, for
> example, is a very bad irq to try to use.  In the Linux driver, only
> device drivers who register their interrupt driver with the
> SA_SAMPLE_RANDOM flag actually have the interrupt timings sampled for
> the random number generator.

(Hmm.. Thinks of ways of doing something similar. I'm not functioning too
well right now.)

> People have suggested using making it possible to select at run-time
> which interrupts to sample, instead of at compiling it into the device
> drivers.  I've generally not been convinced this is a good idea, because
> most system administrator won't likely know which irq's are good and
> which are bad for random number generation.  For example, although it
> may not be obvious, the network interrupt may not be a good choice,
> since an adversary who is monitoring the ethernet cable can make a
> pretty good guess about the timing of your network interrupts, and hence
> what the likely inputs are to the random number pool might be.

Are you sure about this? The stochastisity if this would be pretty
hefty. Not only would our attacker have to get the _time_ that the
interrupt occurred (if it interrupted our machine), he would then have
to process in brute-force mode all possible times in his error range.
What is more, more interrupts are coming in...

>    Gimme a yell if you want copies :-)
> 
> Sure, why not.   I'd be interested to see what you did.

Hokay! Please also send me _your_ latest. (BTW - did Linus put it in
his latest kernel?)

M
--
Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger mark at grumble.grondar.za for PGP key