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