On 18/07/14 22:57, Ben Laurie wrote: > Discovering that its OK to use this mechanism seems as vulnerable to > mistakes as the mistakes we've seen. I don't have good suggestions on > how to fix this. I know, this is a scary subject. There is wisdom in a belt-an-braces approach, to keep the PRNG in userland in case the kernel's CSPRNG is weak or glitches sometimes. A counter-example in my mind is the Debian OpenSSL bug - the CSPRNG was accidentally broken and its 'bulletproofing' meant there was still about 15 bits of entropy from getpid, gettimeofday and such. That allowed 2 years to pass before the real problem was noticed, and by then weak keys/certificates were in production use, causing the real damage. If a PRNG is not working, I'd prefer it to output a stream of zeroes, or at least the same sequence on everyone's system so that it is noticed very quickly. I think the amount of code would be reduced and some current concerns become irrelevant if the userland PRNG went away. We already expect the kernel CSPRNG is good if we're seeding from it, and it is used for other things that are important. Or if we're worried about draining entropy too quickly from the CSPRNG, a non-privileged user could do that anyway from /dev/urandom, or it may happen when a server doing crypto work is under stress? Regards, -- Steven Chamberlain [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"