So much entropy it's coming out of our ears?

Chuck Swiger cswiger at
Thu Aug 5 09:03:15 PDT 2004

Robert Watson wrote:
> On Thu, 5 Aug 2004, Mark Murray wrote:
[ ...snip Sam's comments about push versus pull models of
      harvesting entropy... ]
>> Yarrow is not conducive to "water-mark" type flow-control, but I'm
>> looking at replacing Yarrow with Fortuna (code at an advanced stage).
>> This should improve things all-round. 
> Could we do the rate limiting on the sender side, then, by making a
> guestimate at a maximum useful entropy rate?  [ ... ] 
> I.e., add a "entropy_gathered" int that uses a unlocked read to test for
> non-zero, and is decremented while holding one of the harvesting mutexes
> if it's non-zero.  Reset it in a callout a few times a second, and set it
> to some small value, like 4.  This will result in the gathering of some
> entropy each second, but not so much that it seriously hits the packet
> delivery path in higher workloads.

For what it's worth, this sounds like a pretty good approach to me.

Given that Yarrow maintains an estimate of the amount of entropy available, it 
ought to be easy to use that to decide whether "4" or some other value is 
appropriate.  If the entropy pool is "full", leave entropy_gathered == 0, or 
perhaps set it to a small value as Robert suggests so that we're still 
churning a few random bits into the pool.  If entropy is being used, set 
entropy_gathered equal to some bigger value which is appropriate for the how 
much new entropy the pool would like to get over the next interval.

Furthermore, the code which does the entropy gathering might even choose to 
pay attention to how much entropy is desired and alter their sensitivity a bit 
(ie, how many of the least-significant bits from a timestamp based on the 
interval between when the last two packets were received are trusted to be 

[ This part is a good candidate for a sysctl, so those who are concerned about 
the purity of their entropy can choose that the entropy harvesting code be 
pessimistic, whereas others who just want /dev/random to output reasonably 
random stuff without much overhead can choose to get just that, instead. ]

Perhaps change the name from entropy_gathered to entropy_wanted?  That seems 
to best describe what it's being used for...


More information about the freebsd-current mailing list