Re: Increasing entropy

[David Laight <david%l8s.co.uk@localhost>]

On Fri, Jun 08, 2012 at 06:31:54PM +0000, Paul_Koning%Dell.com@localhost wrote:
> 
> From what I remember from reading Schneier's discussion of this topic
> (in the description of the PRNG he designed), the notion of "draining"
> entropy does not make cryptographic sense.
> Instead, what you have in a PRNG is a secure bitstring extender,
> which is seeded with a sufficiently unpredictable bitstring.
> Yes, it's good to add entropy into the mix when you have some,
> but the security property you're looking for is that, knowing large
> amounts of output from /dev/random, you have no practical way to predict
> any of the bits preceding what you know, nor any of the bits following
> what you know.
> And that will be true if the extender is cryptographically secure,
> and the seed has enough entropy that brute force search of the seed
> space is impractical.

I thought tls had been working on those lines?

I've wondered why something like the following wouldn't work.
1) Use the RC4 PRNG as an entropy store, whenever you have anything
   that might be random feed it in using the 'keying' algorythm.
2) When you want some random data, cycle some bytes out of the RC4
   entropy store and then MD5 hash them. Give the users the MD5 output.

Might be worth cycling the RC4 prng a few times before and after taking
data out of it.
You can't use RC4 itself - the data output is recognisable as RC4 data,
but an MD5 (or other) hash should correct that.

At system startup you may need to keep track of the amount of
randomness, but once you have added enough 'randomness', it doesn't go away.

        David

-- 
David Laight: david%l8s.co.uk@localhost