RNG implementations and their problems
>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 [...]
This is a security feature. If non-root programs could write to
/dev/random and update its entropy count, they could lie about the
entropy count and harm others on the system who rely on /dev/random.
By the way, rngd already does pretty much what you want. Have you
looked at it?
It would be pretty easy to hack egd or prngd to periodically feed
the entropy they have gathered into /dev/random, using the appropriate
ioctl()s and root-level access. Seems like that would be good enough.
It would also be trivial to write a 'cat'-like program that takes
data on stdin and uses the appropriate ioctl()s to write it to /dev/random.
Problem solved.
But I am skeptical that this problem is very widespread. I doubt there
are many people who have found this to be a barrier.
I would also question why you are using /dev/random. For most purposes,
/dev/urandom is the right default.
>Reading from /dev/urandom empties the entropy pool immediately; this is
>unfriendly to people who need real random numbers.
Few applications truly need /dev/random. Those applications that do need
/dev/random usually need random numbers only in very small quantities, and
for them, the "deplete the pool" behavior seems like the right semantics.
It is certainly true that there are many poorly-thought out applications
that use /dev/random even though /dev/urandom would have been a
better choice. However, I just can't get too bent out of shape if
those applications suffer as a result of their questionable choice.
Those applications will just have to deal with the consequences of
their misdesign. If it becomes a problem, maybe that will be sufficient
motivation for them to reconsider their use of /dev/random and switch
over to /dev/urandom, like they should have done in the first place.
Anyway, on the question of whether to use write() or ioctl() to update
the entropy pool from user land, my suspicion is that the current
semantics just hasn't been a very big problem for anyone, and so no
one has cared enough to bother writing code to change the behavior.
It's also not clear to me that current interface is problematic or
that your suggestion is a better choice. But in any event, if you
are motivated enough to try to write code and submit patches that
would implement your preferred solution, you should probably take this
discussion over to the linux-kernel mailing list.
>Getting good randomness shouldn't be platform-specific,
>and shouldn't fail in silent or unsafe ways at runtime.
I'm not sure what this is referring to. As far as I know, /dev/{u,}random
doesn't fail in silent or unsafe ways at runtime.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RNG implementations and their problems
At 10:54 PM -0600 12/3/05, Travis H. wrote: I'm dissatisfied with the state of /dev/random devices on Unix. Depends on what you mean by "Unix". FreeBSD 5 and 6 have much of what you want. So far I haven't seen any userland tools for updating the entropy count. From 'man 4 random': If the device has is using the software generator, writing data to random would perturb the internal state. This perturbation of the internal state is the only userland method of introducing extra entropy into the device. If the writer has superuser privilege, then closing the device after writing will make the software generator reseed itself. This can be used for extra security, as it immediately introduces any/all new entropy into the PRNG. 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. The software random device may be controlled with sysctl(8). To see the devices' current settings, use the command line: sysctl kern.random which results in something like: kern.random.sys.seeded: 1 kern.random.sys.burst: 20 kern.random.sys.harvest.ethernet: 0 kern.random.sys.harvest.point_to_point: 0 kern.random.sys.harvest.interrupt: 0 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 100 kern.random.yarrow.slowthresh: 160 kern.random.yarrow.slowoverthresh: 2 (These would not be seen if a hardware generator is present.) All settings are read/write. Thus, you can do your own calculations and change the paramters to your heart's content (assuming you have root privs). (...Other Linux-specific complaints elided...) --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RNG implementations and their problems
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]
