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 [EMAIL PROTECTED]
