On Thu, 22 Jul 1999, John Denker wrote:
> Here are some comments and a proposal:
>
> 1) Linux /dev/urandom can be considered a PRNG with some good properties
> but two suboptimal properties:
> 1a) First it reseeds too much, and then
Actually, the problem is that it *requires* too much reseeding. You can
never do 'too much' reseeding, at least not given the bandwidth of current
sources of entropy.
I'm not sure what acronym you have in mind with TRNG, but that does give
me an idea for what to call 'a cryptographic primitive which generates
random-looking output and can have real entropy mixed into the pool in
such a way that a malicious attacker can't predict or control future
output if enough etropy has been mixed in despite arbitrarily large
amounts of malicious feeding in of data and reading of data.' - SRNG, for
Somewhat Random Number Generator, that way PRNG can still mean Pseudo
Random Number Generator. Come to think of it, by TRNG you probably meant
Truly Random Number Generator. I like that terminology.
> 3) The yarrow design contains some good ideas, but the existing yarrow code
> cannot easily be dropped into the linux /dev/urandom device or the linux
> IPsec machinery.
That should be fixed. The best way to solve this problem is to completely
get rid of the old /dev/random and /dev/urandom code and replace them with
a single robust device - that way *all* old applications which have
potential depletion attacks will get fixed, not just ones pointing at a
new device or using a new library.
> In particular, consider the following reseeding schedule:
> a) Every N minutes...
> b) Every Z bits of PRNG output...
> c) As soon as a quantum of TRNG material is available ...
> ... whichever comes *LAST*, and where N and Z are chosen to ensure a good
> leverage ratio.
a) and b) don't help much - the true answer is c).
As for getting entropy when the machine is first started up, it will have
to block a bit until enough is collected, but after that is done once it
can purr right along.
-Bram
