> On 23 Jul 2015, at 18:30, Alexey Dokuchaev <da...@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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
