Date: Sat, 25 Jul 2015 22:51:25 +0100 From: Mark R V Murray <markm@FreeBSD.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: src-committers <src-committers@FreeBSD.org>, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org 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... Message-ID: <481EBEBF-6CDF-4A61-A66C-A35A5933805D@FreeBSD.org> In-Reply-To: <20150725174659.GW78154@funkthat.com> References: <FFAED695-145A-45F5-988D-B843EF5F544B@FreeBSD.org> <alpine.BSF.2.20.1507221249120.1071@desktop> <FFFB06D7-164B-40B3-AFC3-A6630BCF074E@bsdimp.com> <E20B169F-4C8A-4D11-9853-5C2EFC116450@FreeBSD.org> <F54A96A8-D9AD-409A-814F-538B6AD3CD50@yahoo.com> <20150724012519.GE78154@funkthat.com> <BC734D25-375C-4C1C-BA8A-BD91158B6A39@FreeBSD.org> <96EA33AB-7325-4DD2-83F4-B4FAF6F47CB5@yahoo.com> <20150725062651.GU78154@funkthat.com> <30C50677-D00A-46B3-AF7A-62FC299D409F@FreeBSD.org> <20150725174659.GW78154@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 25 Jul 2015, at 18:46, John-Mark Gurney <jmg@funkthat.com> 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 <jmg@funkthat.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?481EBEBF-6CDF-4A61-A66C-A35A5933805D>