Hi Folks --
Thanks to all for the nice discussion.
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
1b) it reseeds in dribs and drabs.
That is:
1a') When there is entropy in the pool, it gobbles it all up before
acting like a PRNG. Leverage factor=1. This causes other applications to
stall if they need to read /dev/random.
1b') When the pool is depleted, /dev/urandom acts like a PRNG but reseeds
itself in dribs and drabs as TRNG entropy becomes available. This leaves
it vulnerable to an iterated guessing attack.
2) There are plausible threat models that motivate some modest level of
concern about iterated guessing:
2a) Suppose some poor sysadmin leaves a *widely-readable* copy of the
keyfile around somewhere, then fixes it by making it root-readable only,
without being smart enough to totally reseed at that point.
2b) Suppose the attacker briefly gets root access. Such an attacker
*could* do something much worse than merely reading the keyfile -- but
might be afraid to. Altering the system has to be done very carefully or
it will leave fingerprints.
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.
4) It would be relatively easy to change /dev/urandom to use quantized
reseeding with a quantum large enough to defeat iterated guessing. (The
terminology "quantized reseeding" seems preferable to "catastrophic
reseeding", which seems unduly pejorative.) This solves problem (1b).
5) So let's talk about solving problem (1a). For clarity, let's talk in
terms of a new device /dev/vrandom. Consider the following possible
design: We use code similar to the existing /dev/urandom, EXCEPT that it
does not share its internal state with /dev/random or /dev/urandom. The
new device initializes its state from /dev/random or some other TRNG. (We
*really* want the initial state to be really random.) For a stripped-down
host on which TRNG bits are scarce or unavailable, this initialization is
done "at the factory". Thereafter it performs quantized reseeding often
enough to fend off iterative guessing attacks but not so often as to
deplete the TRNG.
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.
================
So, folks, does this look like a solution that everybody can live with?
Does anybody have a better idea?
Thanks -- jsd
