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]

> 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