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
