Well, there are basically two schools of thought on the random number
design. Or perhaps it's fairer to say that we can identify two extremes
along a continuum of RNG design.
One extreme is to put a lot of faith in the crypto; Yarrow, with its
relatively small entropy pool and reliance on the security of the block
cipher, falls in this class. If the cipher is cracked, life is very
unpleasant.
The second emphasizes collecting unpredictability from system
environmental sources and uses the crypto function more as a "whitener"
more than any thing else. The PGP and Linux /dev/random device uses
this approach. Basically, it uses a very large entropy collection pool,
so that even if the cryptographic function is cracked, the chances that
anyone could actually deduce the entropy pool (and thus predict future
random nunbers is very small). Indeed, as long as sufficient system
unpredictability continues to flow into the pool, this problem can be
made quite intractable.
The second approach appeals to those who are paranoid about the
potentially unknown problems in <insert your favorite crypto here>,
since it relies less on the cryptographic properties of the crypto. On
the other hand, it's much more dependent on being able to get sufficient
amounts entropy which can't be predicted by an adversary.
I've had mixed feelings about including /dev/urandom, and perhaps I
wouldn't have included it considering what I know now. Removing it and
changing the threshold at which /dev/random blocks so that it will only
generate randomness when there are at least 128 bits of estimated
entropy in the pool would make it *much* more difficult to carry out the
sort of attack which Yarrow posits. (I've never considered the attack
posited by the Yarrow paper to be that troubling, in any case, since it
requires shell access on the machine to be attacked, and on just about
all modern Unix systems, if you have shell access on the machine you can
probably break root trivially anyway.)
As far as changing Linux's /dev/urandom to use a counter-style based
block cipher, my big question is why bother putting this in the kernel?
There's no reason to do so; there's nothing special it needs to do which
*has* to be done in kernelspace. (This makes it unlike the /dev/random
driver, which relies on being able to capture a lot of system entropy
from instrumenting the kernel.)
Making a generic library which applications can call to get good
pseudo-random number generator would definitely be a good thing. I
don't quite see the point of putting it in the kernel, though.
- Ted
