Linus Torvalds wrote:
>If you make /dev/random useless ("but you can use /dev/urandom instead")
>then we should not have it.
There's a purpose for /dev/random, but it's a special case.
For the common case, /dev/urandom is a much better choice
than /dev/random. Sadly, the naming was poorly chosen, IMHO;
I feel /dev/urandom ought to be the default choice, and /dev/random
should be only for those who know what they're doing and have
a special need.
The special case where /dev/random is needed is applications
that (1) are managing their own user-level randomness pools,
(2) need forward security, and (3) can't rely on the kernel to
provide the forward security.
In more detail:
(1) Why would an app want to manage its own randomness pool?
I don't know, but possibly for better performance.
(2) Suppose someone breaks into your firewall / IPSec gateway.
You don't want them to be able to muck through memory and
deduce all past and future session keys. The solution?
Once a day, you collect 128 bits of true randomness and do
a "catastrophic reseed": you hash them into the pool all at
once. Then you can be sure that anyone who breaks into your
machine won't be able to get more than a day's worth of past
IPSec keys, and once you kick the hacker off, they won't be
able to predict more than a day's worth of future keys.
(3) The kernel should be doing catastrophic reseeding of
/dev/urandom's pool. However, if the application manages
its own randomness pool, it will need to take responsibility
for doing its own catastrophic reseeding.
If all these conditions are satisfied, the application will need
true randomness, so that it can do its catastrophic reseeding.
But this doesn't seem to be the common case, as far as I can tell.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Aug 23 2002 - 22:00:24 EST