From owner-svn-src-head@freebsd.org Sat Jul 25 21:51:36 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 E26C19ABA2A; Sat, 25 Jul 2015 21:51:35 +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 A6827133E; Sat, 25 Jul 2015 21:51:35 +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 1ZJ7Lv-000Olr-3c; Sat, 25 Jul 2015 22:51:31 +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: <20150725174659.GW78154@funkthat.com> Date: Sat, 25 Jul 2015 22:51:25 +0100 Cc: src-committers , svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <481EBEBF-6CDF-4A61-A66C-A35A5933805D@FreeBSD.org> References: <20150724012519.GE78154@funkthat.com> <96EA33AB-7325-4DD2-83F4-B4FAF6F47CB5@yahoo.com> <20150725062651.GU78154@funkthat.com> <30C50677-D00A-46B3-AF7A-62FC299D409F@FreeBSD.org> <20150725174659.GW78154@funkthat.com> To: John-Mark Gurney 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: Sat, 25 Jul 2015 21:51:36 -0000 > On 25 Jul 2015, at 18:46, John-Mark Gurney wrote: >=20 > Mark R V Murray wrote this message on Sat, Jul 25, 2015 at 09:22 = +0100: >>> On 25 Jul 2015, at 07:26, John-Mark Gurney wrote: >>>=20 >>> Once you have enough useful bits in /dev/random, you can NEVER run = out >>> of useful bits from /dev/random... >>>=20 >>> [Well, not quite NEVER, but not for a few millennia.] >>=20 >> So is your position effectively anti-harvesting, or at least to turn >> off all harvesting after a certain time and never turn it on again? >=20 > No, I am not, I was just stating a fact of how CSPRNGs work that > people keep forgetting=E2=80=A6 I think you need to consider the attack/recovery practicalities as well as the theory. > I'm totally against massive collection that has minimal benefit, > but massive performance costs... I raised this issue in the review > and you still haven't disabled INODE collection, plus you admitted > that you hadn't done benchmarks on the uma case=E2=80=A6 Are you following my conversation with ScottL? I=E2=80=99ve agreed this. > It's way more important to have a good seed at first boot for your > rng when you generate long term ssh keys and the like than it is to > continually collecting high rate randomness from the system=E2=80=A6 And that is what the current setup achieves, or achieved. What I had set up was a high-rate collection to unlock the RNG, and the faster stuff was disabled at multi-user time. Unfortunately, even those remnants were too much for UMA, so they will be disabled more permanently. No worries - back to the design board! >> If so, we are pretty far apart philosophically. >>=20 >> DJB???s position is interesting, but I am far from persuaded by it. >=20 > What points are you not persuaded by? Are there any questions that > I could get answers for that would persuade you to change your > mind? The passage of time will do it, I think. I don=E2=80=99t see much overt support for this (I will look out for it), but crucially I=E2=80=99m not aware of a great deal agains it. Its just too, erm, individual right now. :-) > I'm not against continually collecting entropy, I just don't think it > needs to be high speed, or that frequent.. My suggestion is for a > thread to run every few seconds to grovel around collecting some > entropy, and adding it... Obviously low perf impact collection points > like the keyboard should remain as that continues to one of the best > sources (when active/available)=E2=80=A6 The position of the Fortuna authors is that harvesting should be fast enough to thwart attack, and attack is facilitated by reading. Thus a high-speed reader should be backed by a proportionally high-speed harvesting. For ScottL the randomness requirements are low-ish. For (say) a bank, they may be a lot higher, and I see no reason to deny them this if they have no high throughput requirements. M --=20 Mark R V Murray