Date: Thu, 13 Sep 2012 23:05:51 +0100 From: RW <rwmaillists@googlemail.com> To: freebsd-security@freebsd.org Cc: Arthur Mesh <arthurmesh@gmail.com>, Doug Barton <dougb@FreeBSD.org>, freebsd-rc@freebsd.org, obrien@freebsd.org, Xin Li <delphij@delphij.net> Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <20120913230551.7f299ffc@gumby.homeunix.com> In-Reply-To: <E1TCEeB-000InE-N6@groundzero.grondar.org> 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> <E1TCEeB-000InE-N6@groundzero.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 13 Sep 2012 20:00:19 +0100 Mark Murray wrote: > > 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,... FWIW the theory is that if an attacker can insert known data that has a non-zero entropy estimation then they might repeatedly bring forward reseeds resulting in the entropy from other sources being dribbled into the generator in insecure amounts. > > 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 discussion was about replacing the single /entropy file, not having many files. > 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. There are two possibilities here depending on whether you close the device between dribbles or keep it open. In the former case you're repeatedly forcing reseeds and clearing the entropy counters - dribbling entropy into the generator is precisely what Yarrow was designed to avoid. In the latter case you either have to block the boot, which will be unpopular, or dribble in the background in which case it may be too late. For example geli keys for encrypted swap are generated almost immediately after initrandom. Ideally everything should go in in a single write, as early as possible, and Yarrow should be left to work the way it was designed to work. > Compressing the gathered stuff is a good idea, Compression is a very bad idea, it uses more CPU cycle as sha256 without guaranteeing an output that fits comfortably into 4kB.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120913230551.7f299ffc>