On Fri, Sep 14, 2012 at 3:59 PM, Mark Murray <[email protected]> wrote: >> 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. I used to like this idea, but it can break pretty badly if you repeat input, so in the end I decided hashes were the only safe way. > >> 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 > > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "[email protected]" _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"