entropy depletion

[Ian G]

William Allen Simpson wrote:

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


I'm sorry, I don't see the relationship
between the requirement to not leak,
and the requirement to deliver a quantifiable
result.

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



That seems to address the "trivial implementation"
rather than the requirement?

(In practice, I'd be inclined to not so much reset the
pool after every read, but flush or discard a certain
amount that is calculated to reduce any cross read
leakage.  But yes, the requirement may prove to
present some interesting challenges to the implementor.)


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


Zooko and I struck this issue in our recent SDP1.
As a datagram secret key layout, it uses a lot of
secret keying material.  The way we resolved it was
to set a requirement for quality in the key exchange
phase, which derived from a requirement to reduce
the complexities of the datagram encryption phase
(for programming reasons, not crypto reasons);  in
effect we punted the problem upstairs and put all
the load on the key exchange phase.

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