entropy depletion

[Ian G]

Ben Laurie wrote:

> William Allen Simpson wrote:
>
>>> Why then restrict it to non-communications usages?
>>
>>
>>
>> Because we are starting from the postulate that observation of the
>> output could (however remotely) give away information about the
>> underlying state of the entropy generator(s).
>
>
> Surely observation of /dev/urandom's output also gives away information?
>

Right.  I'd suggest the original statement of the
issue at hand might be better rephrased as:

The *requirement* is that the generator not leak
information.

This requirement applies equally well to an entropy
collector as to a PRNG.

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...

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.)

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/


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