entropy depletion

William Allen Simpson wsimpson at greendragon.com
Tue Jan 11 15:48:32 EST 2005


Ian G wrote:

> The *requirement* is that the generator not leak
> information.
>
> This requirement applies equally well to an entropy
> collector as to a PRNG.
>
Now here we disagree.  It was long my understanding
that the reason the entropy device (/dev/random)
could be used for both output and input, and blocked
awaiting more entropy collection, was the desire to
be able to quantify the result. 

Otherwise, there's no need to block.

> For an entropy collector there are a number of ways
> of meeting the requirement.
>
> 1.  Constrain access to the device and audit all
> users of the device.
>
> 2.  set the contract in the read() call such that
> the bits returned may be internally entangled, but
> must not be entangled with any other read().  This
> can trivially be met by locking the device for
> single read access, and resetting the pool after
> every read.  Slow, but it's what the caller wanted!
> Better variants can be experimented on...
>
Now I don't remember anybody suggesting that before!  Perfect,
except that an attacker knows when to begin watching, and is assured
that anything before s/he began watching was tossed.

In my various key generation designs using MD5, I've always used
MD-strengthening to minimize the entanglement between keys. 

There was MD5 code floating around for many many years that I wrote
with a NULL argument to force the MD-strengthening phase between
uses.  I never liked designs with bits for multiple keys extracted
from the same digest iteration output.

And of course, my IPsec authentication RFCs all did the same.  See
my IP-MAC design at RFC-1852 and RFC-2841.

> We are still left with the notion as Bill suggested
> that no entropy collector is truly clean, in that
> the bits collected will have some small element of
> leakage across the bits.  But I suggest we just
> cop that one on the chin, and stick in the random(5)
> page the description of how reliable the device
> meets the requirement.
>
> (This might be a resend, my net was dropping all
> sorts of stuff today and I lost the original.)
>
That's OK, the writing was clearer the second time around.

-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list