Re: [PATCH] (0/4) Entropy accounting fixes

[daw@mozart.cs.berkeley.edu (David Wagner)]

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.