Re: Summary re: /dev/random

[bram]

On Mon, 2 Aug 1999 [EMAIL PROTECTED] wrote:

> Linux's /dev/random uses a very different design, in that it uses a
> large pool to store the entropy.  As long as you have enough entropy
> (i.e., you don't overdraw on the pool's entropy), /dev/random isn't
> relying on the cryptographic properties as much as Yarrow does.

The problem is that the one bit of entropy for one bit of output rule
creates the potential for lots of denial of service attacks where the
entropy gets used up. There is no application which needs that amount of
entropy. John Kelsey put it pretty well earlier this thread:

  Suppose God, in a fit of budget-consciouness, decides to get
  rid of all this wasteful hardware for generating random
  numbers that are necessary for quantum mechanics, and
  instead replaces them with a PRNG with a 256-bit seed.  In
  this case, all hardware noise sources are ultimately tapping
  into this same seed and PRNG. How will you, or anyone, tell
  the difference?

Most people don't know the fine-grained distinction between /dev/random
and /dev/urandom. In fact, I'll bet most developers don't even know that
/dev/urandom exists. As a result, lots of programs which require very
large amounts of random numbers suck data out of /dev/random, creating a
very large potential for unknown numbers of present and future problems.
This entire class of problems can be eliminated completely by altering
/dev/random to only block at bootup until it has enough entropy (or not at
all if there was some stored on disk) and thereafter to spit out data as
soon as it's requested.

The complete threat model for RNG's, admittedly, has a number of attacks
which seem very impractical under current circumstances, but since those
attacks can be completely eliminated now prudence indicates doing so. That
way, when circumstances arise in which one of those attacks is practical,
we can make a little academic note which nobody cares about for it, rather
than having to deal with a disaster.

The other reason for changing the way /dev/random currently works is that
the long output version of RIPEMD160 would make it just plain faster,
since it would halve the amount of hashing done per byte of output.

The goal is to make it so that any time someone wants random numbers they
can go to /dev/random, with no required studying of entropy and threat
models and all that yadda yadda yadda which most developers will
rightfully recoil from getting into when all they want is a few random
bytes.

-Bram