On Mon, 9 Jun 2014, Florian Weimer wrote:
I think such warning (and perhaps an advice to use -randfile /dev/random?) should be reflected in documents telling people to use openssl genrsa et al. to generate keys.
"-randfile /dev/random" hopefully does not offer any real benefit.
BTW: A small erratum: the correct name of the option seems to be "-rand" rather than "-randfile". I am sorry I got it wrong.
It guarantees that keys are generated from good entropy. How that can't be a real benefit?
Unfortunately, it turns out OpenSSL is very entropy-hungy and it sucks 2048 bytes every time it gets a device as a parameter to "-rand". This means it drains the kernel entropy pool pretty quickly, it takes a long time to finish and most of the precious bits of entropy are wasted. :(
Come to think of it, maybe it would also be a good idea to patch these commands to print the warning when they are used to generate new keys without a good source of entropy.
Currently, there is no non-blocking way to detect that the kernel pool has been initialized. I proposed a patch to add a variable under /proc/sys, but that wasn't accepted. [...]
There are three possible levels:
0. Generate the key and do not care about entropy. This is listed merely for the sake of completeness. I hope (against all odds) no one is ever going to do that intentionally.
1. The key may be generated using recycled entropy as long as the recycling is done by a cryptographically secure generator and the amount of entropy used to seed the generator is sufficient.
2. The key shall be generated using fresh entropy--or a dedicated generator seeded with a sufficient amount of fresh entropy.
Personally, I think the second level should be preferred for any long-term keys. But it would not make sense to do any checks in this case because there would be a race condition between the check and an attempt to acquire the entropy. One can do a non-blocking read from /dev/random.
Unfortunately, the device is designed to return chunks of EXTRACT_SIZE bytes and it is not possible to acquire more entropy atomically (all or nothing). One could read_wakeup_threshold sysctl but I do not think it would help.
A process that would hit the bottom of the pool in the middle of reading would have to throw out any bytes it has read so far, or--it is privileged--feed them back to the kernel.
If the first level is sufficient for you and your kernel is >= 3.11 then it seems to me everything you need to do is to check whether kernel.random.entropy_avail sysctl or RNDGETENTCNT ioctl return a nonzero value and read from /dev/urandom. Kernels since 3.11 always seed the nonblocking pool with at least 128 bits (the number is hardwired) before they start adding bits to the input pool.
An alternative, purely userspace, solution that would work on any kernel could be as follows: start a background process that
1. acquires a given amount of entropy from /dev/random,
2. feeds it to /dev/urandom (in fact, it does not really matter where the data are written because they are always mixed into both pools)
3. raises a flag telling everyone /dev/urandom has been seeded and exits.