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...

[Mark R V Murray]

> On 23 Jul 2015, at 18:30, Alexey Dokuchaev <danfe at FreeBSD.org> wrote:
> 
> [ Guys, please teach your MUA to wrap messages over 72-76 boundary and trim
>  excessive/irrelevant quoting, thank you. ]

Oops sorry!

> 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.)

Accurate.

> 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.

Again accurate.

> 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?

This is already present, but some if these checks, while very cheap, are
still too expensive in very high-performance areas of the code.

> 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?

No. Not an absolute “no”, but The Yarrow algorithm required this, and it
was never implemented satisfactorily by anyone due to its difficulty.
Yarrow is now no longer supported by its authors due to this, amongst
other problems.

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

Sort of. By turning on the RANDOM_DEBUG option, Fortuna will periodically
print out the “message lengths” of all 32 accumulation pools. These are
very vaguely indicative of the accumulated entropy. Pool[0] is used for
reseeding; the rest are there for my interest and will be removed at some
point.

M
-- 
Mark R V Murray