[VirtIO RNG] Clarification re: Using /dev/urandom vs /dev/hwrng ?

[SInisterPisces]

Ref: https://www.kernel.org/doc/html/latest/admin-guide/hw_random.html

At some point (don't ask me why, or how), I seem to have convinced myself that using /dev/hwrng for VirtIO RNG in VM hardware configurations was preferred for performance and other reasons.

And from reading the above and some other sources, it does appear that the host CPU's actual hardware RNG can provide the most randomness versus the other options, under the right circumstances. But the tradeoff is that it's potentially blocking if the CPU can't keep up with the requests for randomness.

To that end, it seems /dev/urandom (the default) is recommended because it is (1) non-blocking, (2) draws from multiple entropy sources (it effectively cannot run out and block other processes); and (3) works well enough for all but the most highly-demanding/cryptographically security-sensitive applications.

Questions:

1. In the self-hosting/home server/hobbyist space, is it indeed the recommendation to stick with /dev/urandom?
2. Does the hardware matter (say, an 8th-gen Intel CPU vs. a 12th-gen Intel CPU)?
3. If /dev/urandom is the general recommendation for the self-hosting/home server/hobbyist (or even small business) space, are there any specific workloads where it makes more sense to use /dev/hwrng?

Thanks!

 

[tomservo]

1. Yes.
2. Not really. Linux doesn't depend on any single source of entropy, and the CPU's RNG is just one of many sources used to seed the OS's RNG.
3. The only sort of workload where you worry that much about your random numbers that I can think of is one where an adversary could gather a large sample of random numbers from you rapidly. Consider for example Cloudflare who run some of the Internet's most busy web servers. Making hundreds or thousands of TLS connections per second to probe their RNG would just blend into the background. They use some custom hardware to generate their own random numbers, using some lava lamps (seriously). https://www.cloudflare.com/learning/ssl/lava-lamp-encryption/

If you were making your own RNG like that, using /dev/hwrng as one of your sources of entropy would make sense, since you know where the randomness came from (where /dev/urandom comes from a mix of sources). Other than such special cases, /dev/urandom is usually good enough.

 

[SInisterPisces]

Thanks!

EDIT: Any reason to change the default period or bytes/period in the VirtIO RNG settings? I'm guessing no.

Guess I need to fix all that now. Oops.

 

[tomservo]

None that I know of, but I assume there must be one since the option exists. Maybe for compatibility or safety with older guest OS with less sophisticated RNG?