On Mon, 21 Mar 2022 10:42:07 +1300, Peter Reutemann quoted:
'The most significant outward-facing change is that /dev/random and /dev/urandom are now exactly the same thing, with no differences between them at all, thanks to their unification in random: block in /dev/urandom.'
Just to be clear what is happening here, the original distinction between reading random bytes from /dev/random versus /dev/urandom was that the former always guarantees to have some genuine entropy (physical randomness) to give you, whereas the latter would fake it by falling back to a pseudorandom sequence if it ran out of entropy. So long as there was enough randomness for the starting point, /dev/urandom would produce a stream of bytes that was good enough for most security-related purposes. But for the most security-critical uses (e.g. generation of long-term keys), those who are paranoid might still have preferred to use /dev/random, however long it takes to return a result. A problem could occur on this score during the early stages of booting, before the system had collected enough randomness to seed the random number generator, which could cause hangs on code trying to use /dev/random. This issue seems to be mostly resolved now. What the new kernel changes have done is guarantee that your system will have enough randomness within about one second of booting so that it becomes feasible to use /dev/random as your source of randomness for everything. And /dev/urandom now becomes just another name for this.