On Sat, Sep 15, 2012 at 11:36 AM, Mark Murray <ma...@freebsd.org> wrote: > Ben Laurie writes: >> > I can certainly trigger a reseed at will, but allowing external writes >> > to overwhelm the system by doing a >> > >> > $ cat /dev/zero > /dev/random >> > >> > ... just ain't gonna happen. No, sir. >> >> Let's just quantify the risk here: essentially the problem is that if >> I feed something with no entropy into the pool and that is allowed >> to trigger a reseed, then you end up hashing what existing entropy >> you have with the no-entropy input, leading to a loss of entropy. The >> theoretical loss for a perfect hash function is log_2(N)log_2(1/e), >> where N is the number of iterations. log_2(1/e) is ~.66. So, to reduce >> the entropy from, say, 256 bits, if SHA-1 is used, to 128 bits, takes >> ~2^(128/.66) reseeds - that is, ~2^193. Around 10^58. So, you're >> right, it ain't gonna happen, even if you allow an attacker to reseed >> as often as he wants :-) > > Fine, but that is not what I'm talking about, _AT_ALL_. > > Reseeds are expensive in kernel space; locking/unlocking and thread > consumption are the issue. Right now, this is mitigated by reseeding at > 10Hz. To allow reseeds to overwhelm the running kernel by pumping data > into /dev/random is would be very silly indeed, and I'm not going to let > that happen.
I'm curious what the comparative cost of cat /dev/zero > /dev/null is? Or, cat /dev/zero > somefile _______________________________________________ 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"
