Speed and security of /dev/urandom

[Steven Chamberlain]

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
steven at pyro.eu.org