[5205] in cryptography@c2.net mail archive
Re: linux-ipsec: Re: TRNG, PRNG
daemon@ATHENA.MIT.EDU (Bill Stewart)
Sat Jul 24 16:55:31 1999
Date: Sat, 24 Jul 1999 11:23:54 -0600
To: linux-ipsec@clinet.fi, cryptography@c2.net
From: Bill Stewart <bill.stewart@pobox.com>
In-Reply-To: <4.1.19990722041427.00cc5710@surfcity.research.att.com>
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, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
