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 [EMAIL PROTECTED]
