RNG implementations and their problems

[David Wagner]

>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 majordomo at metzdowd.com