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

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?

• /dev/random is still blocking until the pool collects enough entropy. Then it becomes unblocking. This is the same behavior on FreeBSD (but where /dev/urandom is also blocking in the same manner). Oct 13, 2020 at 15:18
• I'll keep this a while and later will delete this Q; see chat.stackexchange.com/transcript/message/55815314#55815314 Oct 13, 2020 at 16:13
• I'll just post my answer I started to write so that I did not write it for nothing, even though it will be deleted later. I understand why you would delete your question. Oct 13, 2020 at 16:19
• @kelalaka This is now an HNQ, but it hasn't blown up in that way. I think it's actually quite informative. Perhaps changing the title to “are there issues with” (so it doesn't fall afoul of Betteridge's law of headlines) would be better than deletion? Oct 13, 2020 at 20:35
• @kelalaka I think so; now it won't mislead people who are used to only reading titles. (In retrospect “what issues are there” would be even better, and there's probably an improvement to be made on top of that…) Oct 14, 2020 at 6:04

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.

• It's also possible to write into /dev/random to add entropy to the pool. This won't increase the entropy count, (the kernel doesn't trust it) but you can use it to initialize /dev/urandom if you do. This is generally going to be safer than writing your own userspace CSPRNG. Oct 13, 2020 at 16:40
• A little note for IOS: /dev/random and /dev/urandom same in iOS Oct 13, 2020 at 20:40
• I don't think that's quite right. If you cloned a VM w/o rebooting it then /dev/random may well issue duplicate bytes. But I'm more worried about the entropy.bin mechanism that some machines have that assumes you do not duplicate VMs w/o clearing it. Oct 13, 2020 at 23:24
• Could you address the points of Joshua? Oct 16, 2020 at 15:21
• @Joshua According to the Linux kernel documentation at https://github.com/torvalds/linux/blob/master/drivers/char/random.c, it is recommended to store a seed in /var/run/random-seed at shutdown and import it at boot time. This mechanism does not increase the counted amount of entropy. So, at boot time, the estimated amount of entropy is zero and /dev/random is still blocking until it gather enough entropy, even if booted from a VM template. Oct 16, 2020 at 22:04