Skip site navigation (1)Skip section navigation (2)
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>