So here’s the tricky thing to that answer: whilst the Kernel’s /dev/urandom and /dev/random*** suffice for most tasks, when Containers and VMs start to come into the equation the host machine doesn’t always have a high enough entropy pool for safe operation. One or two VMs? Not a big deal. Deploying a hundreds of containers per host, or services that heavily rely on keygen? Things become a bit more complicated.
So It’s a true RNG, but a very fast true rng compared to most solutions. It’s output is safe enough to use as-is, or use it to seed the host’s entropy pool. Can still use /dev/urandom, but it’s Unblocking mode will be safer when there is enough entropy to not re-use bits from the pool. The man page also notes a still undisclosed attack on urandom, and to use /dev/random when the operation is considered particularly sensitive (IMHO, only use it for very long term keys like PGP, Org CAs, and TLS DHParam Keys).
However, when the sink caused by urandom gets to outpace the system, the entropy can drop significantly. That’s where this comes in. It’s fast enough at providing entropy you can fill the pool quicker to prevent the unblocking process from reusing bits to feed the CsPRNGs
Cheers,
-Jim
*** newer non-RHEL systems are starting to use getrandom since Kernel 3.15, but it has the same issue when you have large entropy requirements at scale