Re: randomness

[Roland McGrath]

> I am working on a random translator.  I am using the random pool mixer from
> gnupg, which already does a lot of the work.

Cool.

> What gnupg provides us is an interface where you can poll random bytes from
> a random source like egd or a random device.  In the translator, I want to
> have random sources write to /dev/random (for example, egd can be run at
> boot time and write to /dev/random).  This random data will be mixed into the
> pool, from which random data is drawn via read().



> The obvious problem is that now we need to care about multiple readers, non
> blocking open modes and select().  Here are the issues I am thinking of:

Use term and streamio as your guide for how this should behave.

> * Randomness is a scarce resource.  The pool has only a limited size, and
> once it is empty, it takes a long time until new good random data is
> available.  If there are multiple readers, and new random data only comes in
> slowly, how do I distribute that new randomness? Do I wake up a reader and
> let it get all available data (even if this is less than was requested?),
> and return to the caller?  This seems to be what POSIX suggests.  It would
> also make sure that everyone gets a chance to get a piece of the cake.

The way character devices normally work is to return whatever is available
as soon as it is available to whomever is ready to take it first.  (In
termios, there is always either the line-mode rules or the VMIN/VTIME
settings to determine how much it takes to be "available".)  For
randomness, the smallest natural chunk is the bit, and the smallest
practical amount for a device is a byte, so when there is a byte or more,
then that's what's available.  This is how Linux's /dev/random works, how
pipes work, how TCP sockets work, how terminals not in ICANON mode work, 
how other asynchronous hardware devices work, etc.

> * If select returns, how do I guarantee that some random data is
> available at the next read?

You only have to guarantee that the next read on the device works.  If
there are multiple readers, then it's their problem to race to get their
io_read in first and either block or miss out if they don't get it.  That's
what O_NONBLOCK mode is for.  It's true that the device is readable at the
instant select decides to return, and that's what matters.

> BTW, there is a fast operation mode, which has not those issues, as it can
> never block.  A switch will enable that, and this will be used for
> /dev/urandom.

I presume you mean this synthesizes pseudorandom data from old true
randomness, as Linux's /dev/urandom does.


It would be good to have a read-only kernel "random" device too.  This
would collect the various low-level sources of entropy (interrupt timings,
etc) that kernel device drivers contribute in Linux and BSD.

I guess the translator could just have general support for reading from
character devices of true randomness, and then the kernel device would just
use a vanilla streamio translator and that would be one of the input files.