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.  So what we are looking at here is a requirement
such that we don't leak any internal state.  Traditionally,
the Unix people would do this by a) limiting access to the
resource to root and b) auditing the user of the resource
carefully.  But that's a bit OTT, IMHO.

Another way of doing this is to put in a requirement that
each read is separate and unlinked.  That is, if you do a
read of 1024 bits for some key operation, the contract with
the random device is that entropy might be mixed between
those bits, *but* it isn't mixed with any other read that
might be done.

Trivially, this could be met by throwing away all existing
entropy, locking the entropy for syncronised read, and
waiting until enough fresh stuff was built up.  That might
take a while, but hey, that's the contract that the coder
asked for.  And there are plenty of variants imaginable.

Either way, it seems that restriction is not the only way
to deal with the leakage problem, once we understand that
avoiding the leakage is the requirement.

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