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.
--
Pavel Kankovsky aka Peak "Que sais-je?"
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
