Date: Thu, 13 Sep 2012 20:00:19 +0100 From: Mark Murray <markm@FreeBSD.org> To: RW <rwmaillists@googlemail.com>, obrien@freebsd.org, freebsd-security@freebsd.org, Doug Barton <dougb@FreeBSD.org>, freebsd-rc@freebsd.org, Arthur Mesh <arthurmesh@gmail.com>, Xin Li <delphij@delphij.net>, Ian Lepore <freebsd@damnhippie.dyndns.org> Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <E1TCEeB-000InE-N6@groundzero.grondar.org> In-Reply-To: <20120912104547.1d0061c1@gumby.homeunix.com> References: <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> <20120907015157.GA29497@server.rulingia.com> <20120910135218.GA68128@dragon.NUXI.org> <504E343A.4020802@FreeBSD.org> <20120911064636.GB72584@dragon.NUXI.org> <504EE446.6060500@FreeBSD.org> <20120911082309.GD72584@dragon.NUXI.org> <20120912104547.1d0061c1@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I've been watching this thread, but not responding due to a need to not contribute to controversy and to be able to provide a measured response when I had the resources. I'm responding to this mail out of the thread not for any particular reason. > David O'Brien wrote: > > > > On 09/10/2012 23:46, David O'Brien wrote: > > > > > > > In what way did I suggest we don't need to seed the PRNG? I > > > > simply removed an outdated and incorrect statement. > > > > > > Yes, the comment as it stood was out of date. I'm not sure that > > > removing it (rather than rephrasing it) was the right call. > > > > Doug you're a FreeBSD committer, you know how to use an editor and > > 'svn diff'. Where is your patch suggesting a rephrase? David, please back down; I see more heat than light from you. > It doesn't make any difference. > > When root close the device a forced slow reseed is done (after the > yarrow thread completes feeding the data into yarrow). Since this is > unconditional and clears the entropy accounting, the entropy estimate > is irrelevant to rc.d/, which runs as root. Correct. The original intent, disabled during the whole Matt Dillon bust-up was to start the random device _blocked_. The unblocking mechanism was/is a write to /dev/random, the intent being start-up randomness cached from the previous shutdown, or manufactured by (eg) getting the pound the keyboard and/or wiggle the mouse. This would involve a possible "soft" hang at boot time while the device was unlocked, but was intended to allow the first ssh keys and friends to be securely created. There is a whole minefield of startup scenarios there, and satisfying everybody was a pretty thankless task. > The entropy estimated at zero bits is so that an *unpriveleged* user > can't feed in his own input, corrupt the entropy estimation and > perform a state-extension attack. Yarrow is pretty resistant to this. "cat /dev/zero > /dev/random" won't "dilute" the gathered entropy, but will swamp the harvest queue. > On Tue, 11 Sep 2012 00:12:06 -0700 Doug Barton wrote: > > > I'm also tired of repeating why writing out a new /entropy file at > > boot time makes the system weaker, not stronger. > > That's not really true. The entropy file contains up to 256 bits of > entropy, if yarrow is correctly seeded with that then that entropy > will be in the 256-bit key which will produce a new file that also > contains that entropy. Too many /entropy.* files would be overkill, but done properly, won't hurt. The harvest queue (as pointed out) is limited, and its possible to overwhelm it with excessive input. I'm in favour of doing something to "dribble" the startup suff in, while limiting its length to (say) 1-2 K. Compressing the gathered stuff is a good idea, and inserting that *first* with a delay following would be ideal; 1 second would be sufficient, 2 safer if the machine very busy. After that "chunking" the cached stuff and easing it in slowly would be a Good Thing(tm). Making the harvest queue block (and therefore take everything given to it) is possible, but the locking inside the kernel is not a nice thing to do, and something like "cat /dev/zero > /dev/random" would be a pretty good spanner-in-the-works without some extra cleverness (off the top of my head, /dev/random's harvester could limit its reads to (say) 2K before kicking off the writer with some soft error (EFBIG or EAGAIN?); this way multiple short writes would all work /in toto/). I also like the idea of XORing in excess data rather than dropping it. This could be messy, though. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) Pi: 132511160
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1TCEeB-000InE-N6>