"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-unsubscr...@freebsd.org"
