At 05:14 AM 7/22/99 -0400, John Denker wrote:
>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.
....
>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.

You could help this problem by giving the randomness pool a secret key
that's typed in by the operator, and hashed in with each reseeding and
each output phase.  You'd probably have to store it in a key file as well,
since there may not be an operator keyboard at boot time,
but if you've got an extra 160 bits of information not obtained
from the physical-randomness process, it should be stronger.
The user interface could allow the superuser (or maybe everyone?)
to input a bunch of text that gets SHA1'd together with the existing key.

> 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.

This is a non-problem - once the attacker gets root, you've lost
the game anyway.

                                Thanks! 
                                        Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Reply via email to