svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random sy...

[Alexey Dokuchaev]

[ Guys, please teach your MUA to wrap messages over 72-76 boundary and trim
  excessive/irrelevant quoting, thank you. ]

On Thu, Jul 23, 2015 at 07:45:14AM -0600, Scott Long via svn-src-all wrote:
> > On Jul 23, 2015, at 1:03 AM, Mark R V Murray <markm at FreeBSD.org> wrote:
> > Fortuna was developed to account for many sources of entropy, good and
> > bad alike, and Jeff's observation is an attack on that design. I accept
> > that the randomness of these events is poor, but they are high-rate, and
> > this product of high-rate*low entropy is what I seek. I pulled out
> > numbers with dtrace, and basic statistics showed that the harvesting was
> > not useless. I completely understand that under the right circumstances
> > these numbers might be lousy - please read the Fortuna design document
> > to understand why this doesn't matter. *ALL* entropy inputs to Fortuna
> > are considered attackable, including the dedicated hardware sources.
> > 
> > I have also read cryptanalyses of Fortuna, not all of them to be sure,
> > and so far the design appears strong. The best attack that I have seen
> > (very academic) suggests an improvement which I may incorporate. [...]

Being not a crypto-guy by any means, I find this reasoning sound and fair.
But read on...

> Hi Mark,
> 
> Thanks for making this concession.  I wanted to add a bit of historical
> perspective.  When Yarrow was introduced in the previous decade, it was
> initially wired into nearly all interrupt sources.  It turned out to be
> so expensive to those sources [that in] the end, a lot of code thrash
> happened and the effectiveness of Yarrow was questionable.
> 
> Fast forward to now with your recent work.  If UMA becomes expensive for
> high-speed use, everyone will go back to developing private per-driver
> and per-subsystem allocators to avoid it. [...]  That'll be a huge step
> backwards for FreeBSD.
> 
> I also strongly agree with Jeff's point on the questionable nature of
> this kind of fast-and-monotonic entropy collection, and Warner and Kip's
> point on the finite number of clock cycles available for doing 100Gb
> networking.  If really high quality entropy is desired, won't most
> serious people use a hardware source instead of a software source? [...]
> An academically beautiful entropy system that hamstrings the OS from
> doing other essential things isn't all that interesting, IMO.

So far it looks like this to me (having read no papers):

1) Fortuna attempts to get the most entropy from all available sources,
trusting none of them.  (Which is good.)

2) Some of them might/will cause unwanted performance loss under certain
circumstances, which becomes a show-stopper (finite number of clock cycles
available, etc.) for some use cases.

If Fortuna is so flexible, why can't some of its sources be conditionally
disabled (kernel option/boot.conf/systct) or down-weighted through some
more sophisticated, self-adjusting configuration technique during runtime?

How dynamic it is?  Mark, is there a (algorithmically?) reliable way to
tell how many bits of "good" entropy is being added to the pool, and then
tune the harvesting strategy accordingly?

Is there some sort of restricted, private API to get a clue about current
entropy status?

./danfe