Re: Patch: new random pseudodevice

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

On Fri, Dec 09, 2011 at 06:52:16PM +0200, Alan Barrett wrote:
> 
> Fair enough, but you still seem to be talking about how good a
> CSPRNG it is, whereas my concern is that it's pseudorandom, nor
> random.

So was the output from the old entropy pool.  Again, look at the
implementation!

As soon as you start "accumulating" random bits in any manner that
leaves the old ones in -- that is, does not entirely eliminate them
as inputs to the accumulator function -- even after you "take them
out" -- that is, disclose the accumulator function's output -- you
are dealing in precisely what you say you want not to: cryptographically
secure pseudorandomness.

I understand it's a common misconception about the original Linux
/dev/random device, and our reimplementation of it, that this is not
what it did.  But it's a misconception nonetheless.

To get the property you seem to want, you basically have to buffer
the purportedly "true" randomness into pools, blocks, what have you,
*on input*; you can still use some kind of "pool" construction to
whiten it, but don't flatter yourself that that's more than what you
are doing, because as soon as you use that "true" randomness to produce
any output, if you don't throw it all away and stop using it as input,
cryptographically secure pseudorandomness is precisely and only what
you get from then on.

Charles raised this objection to /dev/random 15 years ago.  I wasn't
smart enough to really get it then.  I do now.

Let me put it this way: before, you may have thought you were getting
some kind of "true" randomness.  You weren't.  Now, you still aren't,
but at least what sits between you and the entropy source is a lot
more clear, and a lot better analyzed

The other thing to consider is that the CTR_DRBG was designed by real
experts (the participants in the SP800-90 process) to _not_
reveal the bits it was keyed with (the same data you were thinking
were "true" random data before) when confronted with the best real
world attacks known.  If you just use the entropy pool contents
directly, that is definitely not the case; and the data that were
given to you _do_ continue to influence the output the pool gives
in the future, which _is_ directly provided to anyone else who asks
for it, and from my point of view, that should worry you a lot more
than someone having a key-recovery attack on AES that can be extended
to the CTR_DRBG.

The bottom line: pseudorandomness is the best you're going to get.  It
might as well be done in the safest way possible, and the old approach
surely was not that.

Thor