Re: svn commit: r239569 - head/etc/rc.d

"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

_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"