Skip site navigation (1)Skip section navigation (2)
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>