Date: Fri, 14 Sep 2012 15:59:50 +0100 From: Mark Murray <markm@FreeBSD.org> To: "Bjoern A. Zeeb" <bz@FreeBSD.org> Cc: Arthur Mesh <arthurmesh@gmail.com>, Ian Lepore <freebsd@damnhippie.dyndns.org>, Doug Barton <dougb@FreeBSD.org>, David O'Brien <obrien@FreeBSD.org>, freebsd-security@freebsd.org, RW <rwmaillists@googlemail.com> Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <E1TCXN0-000NFT-7I@groundzero.grondar.org> In-Reply-To: <alpine.BSF.2.00.1209141336170.13080@ai.fobar.qr> References: <50453686.9090100@FreeBSD.org> <20120911082309.GD72584@dragon.NUXI.org> <504F0687.7020309@FreeBSD.org> <201209121628.18088.jhb@freebsd.org> <5050F477.8060409@FreeBSD.org> <20120912213141.GI14077@x96.org> <20120913052431.GA15052@dragon.NUXI.org> <alpine.BSF.2.00.1209131258210.13080@ai.fobar.qr> <alpine.BSF.2.00.1209141336170.13080@ai.fobar.qr>
next in thread | previous in thread | raw e-mail | index | archive | help
"Bjoern A. Zeeb" writes: > 1) continue to over-[fs]eed as we always did (seems out of question, > no improvement) See below. Solutions are very possible. > 2) compress (as in gzip) the input of better_than_nothing (multiple > people objected, no literature, questionable outcome, speed, still not > great control over how much data we seed) Not a bad idea, but by better handling of stuff written to /d/r this can be made much more useful. Compressing is a very useful entropy distiller in its own right, but is slow. > 3) hash (arch dependent?) the entire input of better_than_nothing in > the shell script (at least a good idea on how much data we seed) Yup; same advantages as compression, but predictably sized output. Like compressing, its slow. Better handling of files witten to /d/r will also help massively. > 4) hash (arch dependent?) individual parts of better_than_nothing in > the shell script (seed more and still know how much data we'd seed) Doable. Useful. > 5) send all data to the kernel but XORing the data together on > overflow in the kernel (can control when buffer full and only then > take action when needed, indepedent on how seed data is chosen, > withdrawn) I've already coded this up :-) (well, similar). This is the "improved file handling" that I was thinking of. Note that I only do it for writes to /d/r, and not for all entropy harvesting. It still largely kills the entropy swamping, and while an attacker can subvert this, the attack would be obvious. I'll send patches (untested) in a couple of hours for discussion. > 6) send all data to the kernel but XORing the data + counter value > together on overflow in the kernel (can control when buffer full and > only then take action when needed, indepedent on how seed data is > chosen, but why XOR?) Variation on above. > 7) send all data to the kernel and hash (arch dependent?) it + counter > value into the buffer on overflow, as in b[n] = H(b[n] + c + i[n]) in > the kernel (can control when buffer full and only then take action > when needed, indepedent on how seed data is chosen, uses standard > technology) Variation on above. M -- Mark R V Murray Pi: 132511160
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1TCXN0-000NFT-7I>