Re: insufficient entropy for rnd

[Greg Troxel <gdt%ir.bbn.com@localhost>]

Daniel Carosone <dan%geek.com.au@localhost> writes:

> On Mon, Aug 25, 2003 at 12:55:22PM -0400, Greg Troxel wrote:
> > Basically, I was commenting on the notion of having 'full entropy'
> > bits as the prime commodity via /dev/random, v.s. second-class bits
> > from /dev/urandom.  If the seed has enough entropy, and the hash
> > construction and the hash are sound, then the multiple outputs should
> > all be unguessable and independent.
> 
> Yes.  They are identical, apart from the blocking property.

Sure, except there is a notion that the /dev/urandom bits might be
deficient in entropy and should not be used.  That's what I was
getting at.

> The idea of putting yarrow (or some similar PRNG) behind urandom
> was to prevent the "don't really care" consumers from starving the
> "really do care" consumers who are prepared to block.

I would have expected to put yarrow in place for the entire system,
and perhaps not to provide a non-blocking full-entropy device.

> > Being deeply worried about having
> > full-entropy bits (which Yarrow is not) to me indicates a distrust of
> > the hash function.  
> 
> No, of its input.

I meant that if one has a secret X of adequate length (say 160 bits)
and computes (loosely speaking - not trying to get the hash function
subtleties right here)

SHA1(X | 0)
SHA1(X | 1)
...
SHA1(X | n)

then for some reasonable n, perhaps 1000, all of the output bits
should be unguessable and usable.  If not, one can argue that the hash
function is broken.

> > But, rnd depends critically on using the hash
> > function for mixing in bits.
> 
> No, for extracting them.  Bits are mixed in using an LFSR construction
> of xor's. See the comments at the top of rnd_pool.c.

Sorry, I was typing too fast and not checking the details.  I meant
for mixing the state bits as they are extracted, to prevent a
requestor of random bits from finding out the state of the pool.

-- 
        Greg Troxel <gdt%ir.bbn.com@localhost>