What issues are there while using Linux's /dev/urandom for generating cryptographic keys?

Question

As of Linux 5.1 the /dev/random no longer uses the blocking pool. There is a talk about the change on the page Removing the Linux /dev/random blocking pool

I believe that Linux's blocking pool has outlived its usefulness. Linux's CRNG generates output that is good enough to use even for key generation. The blocking pool is not stronger in any material way, and keeping it around requires a lot of infrastructure of dubious value.

This series should not break any existing programs. /dev/urandom is unchanged. /dev/random will still block just after booting, but it will block less than it used to. getentropy() with existing flags will return output that is, for practical purposes, just as strong as before.

Lutomirski noted that there is still the open question of whether the kernel should provide so-called "true random numbers", which is, to a certain extent, what the blocking pool was meant to do. He can only see one reason to do so: "compliance with government standards". He suggested that if the kernel were to provide that, it should be done through an entirely different interface—or be punted to user space by providing a way for it to extract raw event samples that could be used to create such a blocking pool.

and later

For cryptographers and others who really need a TRNG, Ts'o is also in favor of providing them a way to collect their own entropy in user space to use as they see fit. Entropy collection is not something that the kernel can reliably do on all of the different hardware that it supports, nor can it estimate the amount of entropy provided by the different sources, he said. (The bolds are mine)

So, what issues are there while using Linux's /dev/urandom for generating cryptographic keys?

Answer 1

Using /dev/urandom to generate cryptographic keys or secrets can be an issue when the state of the OS is not unique. This is the typically case when a VM was just booted from a template: the state of the CSPRNG could be shared among multiple VMs. In cases similar to this one, it is important to use /dev/random or getrandom() instead of /dev/urandom, so that the output of the CSPRNG blocks until it has collected enough entropy.

Of course, VM clones need to be rebooted or booted up from a shutdown state in order for the entropy count to be reset to zero.

The output of /dev/urandom and /dev/random comes from ChaCha20. To consider it insecure to create cryptographic keys once the inner state of ChaCha20 is initialized with enough entropy, one has to either:

• know the inner state of ChaCha20,
• or break the ChaCha20 cipher, which is today considered one of the most secure ones.

The remaining issue is how to count entropy. The Linux kernel is extremely conservative on this point, and the inner state of the CSPRNG most likely have far more entropy than counted (around two orders of magnitude more). However, to count it exactly is mathematically impossible.

Disclaimer: This answer is valid for the Linux kernel from version 4.8 to version 5.9, which is the latest version at the time of writing of this answer. The Linux CSPRNG was heavily refactored in versions 4.8 (introduction of the ChaCha20 cipher) and in version 5.6 (simplification of the architecture), with minor changes introduced in version 4.17 and along the way.