RNG implementations and their problems

[Travis H.]

I'm dissatisfied with the state of /dev/random devices on Unix.  Here
are my gripes:

So far I haven't seen any userland tools for updating the entropy count.

This is unfortunate, because sometimes I generate entropy on one machine
and want to pipe it into the /dev/random pool.

However, I cannot update entropy counts without writing programs that can
do ioctl (meaning C or C++).  This is no good.  Can't we make writes to
/dev/random take some kind of structured form that's easy to do from a
shell script so that we don't have to use ioctls?  Failing that, could
we have a userland tool that can make the requisite ioctls?

The entropy harvesting and estimation code is bound too tightly to the
entropy pool.

It is in kernelspace so cannot do floating point, like measuring
chi-square or Shannon entropy to estimate the amount of randomness.

Reading from /dev/urandom empties the entropy pool immediately; this is
unfriendly to people who need real random numbers.

In Linux, writing to /dev/random and /dev/urandom is absolutely
identical; the data gets mixed in, but the entropy count isn't updated.
The random_write_wakeup_thresh is almost worthless as any woken processes
will probably not be able to update the entropy count, unless they are
specially coded for this purpose.

The write interface isn't exploited thoroughly enough.  If writes to
/dev/random were to block when the entropy pool is full, and writes
to /dev/urandom never blocks. then it greatly simplifies the design of
userland programs that harvest entropy from sources of non-zero cost;
they merely write(2) to /dev/random, and if it doesn't need any more
entropy, then it simply blocks until more is needed.  This way it doesn't
have to pool the entropy pool using ioctl(2).

If we change the semantics, they should be queryable in some way,
because currently the source code or experimentation is the only way of
discerning them.  Getting good randomness shouldn't be platform-specific,
and shouldn't fail in silent or unsafe ways at runtime.

I may take some action to remedy this situation if I am not overlooking
something simple.
--
http://www.lightconsulting.com/~travis/  -><- Knight of the Lambda Calculus
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com