From owner-svn-src-head@freebsd.org Thu Jul 23 21:42:52 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D5C09A8AA8; Thu, 23 Jul 2015 21:42:52 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F6EE1A5E; Thu, 23 Jul 2015 21:42:52 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1ZIOGN-000MIw-MP; Thu, 23 Jul 2015 22:42:48 +0100 Subject: Re: 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... Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <20150723173016.GA86452@FreeBSD.org> Date: Thu, 23 Jul 2015 22:42:41 +0100 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers Content-Transfer-Encoding: quoted-printable Message-Id: References: <201506301700.t5UH0jPq001498@svn.freebsd.org> <20150723173016.GA86452@FreeBSD.org> To: Alexey Dokuchaev X-Mailer: Apple Mail (2.2102) X-SA-Score: -1.0 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 21:42:52 -0000 > On 23 Jul 2015, at 18:30, Alexey Dokuchaev wrote: >=20 > [ 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): >=20 > 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 =E2=80=9Cno=E2=80=9D, 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 =E2=80=9Cmessage lengths=E2=80=9D 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 --=20 Mark R V Murray