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...
Mark R V Murray
markm at FreeBSD.org
Sat Jul 25 21:51:36 UTC 2015
> On 25 Jul 2015, at 18:46, John-Mark Gurney <jmg at funkthat.com> wrote:
>
> 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 at funkthat.com> wrote:
>>>
>>> Once you have enough useful bits in /dev/random, you can NEVER run out
>>> of useful bits from /dev/random...
>>>
>>> [Well, not quite NEVER, but not for a few millennia.]
>>
>> 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?
>
> No, I am not, I was just stating a fact of how CSPRNGs work that
> people keep forgetting…
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…
Are you following my conversation with ScottL? I’ve 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…
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.
>>
>> DJB???s position is interesting, but I am far from persuaded by it.
>
> 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’t see much overt
support for this (I will look out for it), but crucially I’m 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)…
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
--
Mark R V Murray
More information about the svn-src-all
mailing list