Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Aug 2004 08:53:14 -0700
From:      Sam Leffler <sam@errno.com>
To:        Richard Coleman <rcoleman@criticalmagic.com>
Cc:        Robert Watson <rwatson@freebsd.org>
Subject:   Re: So much entropy it's coming out of our ears?
Message-ID:  <200408050853.14374.sam@errno.com>
In-Reply-To: <4112454D.7000507@criticalmagic.com>
References:  <Pine.NEB.3.96L.1040804234812.19039J-100000@fledge.watson.org> <200408042139.52577.sam@errno.com> <4112454D.7000507@criticalmagic.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 05 August 2004 07:33 am, Richard Coleman wrote:
> Sam Leffler wrote:
> >  gathering through fast paths. I've suggested for a long time that
> >  this sort of collection should be enabled only under dire
> >  circumstances and never by default. Regardless the last time I
> >  looked at the entropy harvesting it used a model where entropy was
> >  unilateraly sent for harvest and discarded when too plentiful. I
> >  term this the "push model". I've advocated a "pull model" where the
> >  PRNG requests entropy when a low water mark is hit and/or a hybrid
> >  scheme where producers have some sort of flow control or feedback
> >  mechanism.
> >
> >  Everything that goes on inside the PRNG is a separate issue.
> >
> >  Sam
>
> In general, by using a push model, you open yourself up to the possibility
> that the attacker could exhaust the entropy at just the right time so he
> can control what entropy is harvested on the next run of the PRNG.  But in
> this case, we might be able to get away with it, since the PRNG is still
> cryptographically strong even when there is no new entropy flowing into the
> system (as long at the attacker doesn't know the initial state of the
> pool). Rekeying and reseeding the pool are primarily to give you forward
> security and to recover if the entropy pool has been compromised.
>
> But a push system is still better if it doesn't impact performance too
> much.

Push vs pull and exhaustion depends on your system config which is why I 
hedged with "or a hybrid scheme".  If a system has a reasonable h/w entropy 
source it should be able to pull enough entropy on demand to keep everyone 
happy.  I know this to be true for at least 4 crypto parts that include a h/w 
RNG.  On systems like this you want to just shutdown all other forms of 
entropy gathering unless you're paranoid about having a single source of 
entropy.

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408050853.14374.sam>