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

>    > > On this same track, I suggest that "/dev/random" devices for unix are
>    > > an excellent idea. Ted Tso did one for Linux that steals all the bits
>    > > of semi-random timing information it can.
>    >
>    > Anyone know where I can find more information on this wonderful device?
> 
> I've just sent patches (versus the Linux 1.3.28 kernel) off to Linus.
> There's a fairly long exposition at the beginning of
> drivers/char/random.c which explain its theory of operation.

A colleague drew my attention to this, and I was so pleased with it that
I ported it to FreeBSD.

I kept the interface as close to the original as I could, but made some
changes for efficiency and ease:

1) I turned the huge comment at the top explaining the theory of operation
into a man page (random(4)).

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.

Gimme a yell if you want copies :-)

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

Date: Mon, 30 Oct 1995 20:16:24 +0200
   From: Mark Murray <mark@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. 

   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.

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.

   Gimme a yell if you want copies :-)

Sure, why not.   I'd be interested to see what you did.

						- Ted