entropy depletion

[Daniel Carosone]

On Tue, Jan 11, 2005 at 03:48:32PM -0500, William Allen Simpson wrote:
> >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.

The point is interesting and well made, but I'm not sure it was
intended as a concrete implementation proposal.  Still, as long as
it's floating by..

Rather than locking out other readers from the device (potential
denial-of-service, worse than can be done now by drawing down the
entropy estimator?), consider an implementation that made random a
cloning device.  Each open would create its own distinct instance,
with unique state history.

One might initialise the clone with a zero (fully decoupled, but
potentially weak as noted above) state, or with a copy of the base
system device state at the time of cloning, but with a zero'd
estimator. From there, you allow it to accumulate events until the
estimator is ready again.  Perhaps you clone with a copy of the state,
and allow an ioctl to zero the private copy.. perhaps you only allow a
clone open to complete once the base generator has been clocked a few
times with new events since the last clone.. many other ideas.  Most
implementations allow data to be written into the random device, too,
so a process with a cloner open could add some of its own 'entropy' to
the mix for its private pool, if it wanted additional seeding
(usually, such writes are not counted by the estimator).

The base system device accumulates events while no cloners are
open. You'd need some mechanism to distribute these events amongst
accumulating clones such that they'd remain decoupled.

It's an interesting thought diversion, at least - but it seems to have
as many potential ways to hurt as to help, especially if you're short
of good entropy events in the first place.

Like smb, frankly I'm more interested in first establishing good
behaviour when there's little or no good-quality input available, for
whatever reason.

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20050127/2633bfc5/attachment.pgp>