Re: Patch: new random pseudodevice

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Fri, Dec 09, 2011 at 02:23:34PM -0500, Mouse wrote:
> 
> You appear to think that anything that's not pure true randomness must
> be pure PRNG.  The old randomness pool was neither; it was a hybrid.

I think we have a basic disagreement here.  I don't grant that there
is such a thing as "hybrid" true randomness.

> 
> I'd still rather fix it right.  If you go ahead with inflicting a PRNG
> on /dev/random, it really really needs to be prominently marked as
> being a PRNG even for the stronger device, since that's a nontrivial
> regression over previous versions (which may not have been perfect, but
> did return at least _some_ real randomness in the bits it produced, the
> exact amount depending on how good the mixing was and how good the
> input estimates were).

What is "real randomness in the bits" and why is it not in the bitstream
produced by the CTR_DRBG keyed from the entropy pool?

I *am* going to replace the entropy pool with Fortuna, which has several
appealing properties that are not exactly what you want, but head in
that general direction.  In particular, the output stage of Fortuna is
designed to recover from disclosure of output bits in, at worst, a
constant time factor when compared to a system directly replacing the
output stage bits with input bits.  But I'm not going to ignore the
recommendations of every authoritave source in the field that I can find
and simply remove the output stage (see below).

There is a class, incidentally, of modern hardware RNGs that are designed
for direct use by applications to generate key material (for example, the
very well documented new Intel CPU RNG).  They push all bits through
the CTR_DRBG or one of its predecessor stream generators before output
This is not an ideal design choice for a source that is intended to be
used as input to another RNG; but it is a very good one for a source that
is intended to be used to key cryptosystems, since it protects the state
of the raw entropy source itself from attack.

> As an application author, I'm not sure.  From a point of view of making
> the device fit the use, I would like to see
> 
> (1) Strong bits suitable for direct use as things like crypto keys.
> Using a PRNG here, even a really good one, is a major fail.

This may be your opinion, but it differs radically from the opinion of
almost every expert in the field of which I am aware.  Notably, it differs
from the opinons of the people who wrote the several relevant FIPS and
X9 standards, who _require_ that cryptosystem keys be generated by an
approved DRBG (their terminology for a CSPRNG) -- though they also
impose minimum entropy requirements for keying the DRBG itself -- and
of SP800-90, which explicitly discusses this issue.

I value your point of view on this.  But I value theirs, collectively,
more.

Thor