> On 25 Jul 2015, at 18:46, John-Mark Gurney <j...@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 <j...@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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"