While it may be generally better to use /dev/urandom, what about the Mining Your Ps and Qs paper?[1]. It finds that:
> Every software package we examined relies on /dev/urandom to generate cryptographic keys; however, we find that Linux’s random number generator (RNG) can exhibit a boot-time entropy hole that causes urandom to produce deterministic output under conditions likely to occur in headless and embedded devices. In experiments with OpenSSL and Dropbear SSH, we show how repeated output from the system RNG can lead not only to repeated long-term keys but also to factorable RSA keys and repeated DSA ephemeral keys due to the behavior of application-specific entropy pools.
This is mentioned a little at the end of the article. Would it be a breaking change for Linux to block urandom at startup?
Read 32 bytes (i.e., 256 bits) from /dev/random, write them to /dev/urandom, and then use /dev/urandom for everything.
And every few months, send an email to Ted T'so with a patch fixing this behaviour. Maybe if every single Linux user bugs him he'll finally capitulate.
1. That was exactly what I was thinking would work best as a workaround if your program might run at boot-time.
2. Perhaps somebody could create one of those preloaded email forms like those political organizations do where you fill in your name and email and it does the rest up to and including sending the email?
It's unfortunate, but this issue lends a kernel of truth to all of the hysteria. /dev/urandom IS flawed. It is unfortunate, but the linux kernel has two different kernel RNG devices, and they are both different from proper security practice.
> Every software package we examined relies on /dev/urandom to generate cryptographic keys; however, we find that Linux’s random number generator (RNG) can exhibit a boot-time entropy hole that causes urandom to produce deterministic output under conditions likely to occur in headless and embedded devices. In experiments with OpenSSL and Dropbear SSH, we show how repeated output from the system RNG can lead not only to repeated long-term keys but also to factorable RSA keys and repeated DSA ephemeral keys due to the behavior of application-specific entropy pools.
This is mentioned a little at the end of the article. Would it be a breaking change for Linux to block urandom at startup?
[1] https://factorable.net/weakkeys12.conference.pdf