Problems emerge for a unified /dev/*random

Posted Mar 29, 2022 22:02 UTC (Tue) by jepler (subscriber, #105975)
Parent article: Problems emerge for a unified /dev/*random

Ages ago I made a random number generating device and a daemon for adding its entropy into the system. So I had to check out today how I did it back then (circa 2013): https://emergent.unpythonic.net/01257868826

It appears that I (A) asked the kernel how much entropy was available via /proc/sys/kernel/random/entropy_avail, (B) if it was at least 3072, slept (max entropy was/is 4096?) (C) otherwise, read enough data from my device, wrote it to /dev/random (not urandom!), and credited it with ioctl RNDADDTOENTCNT

So in this case, it looks like big gulps of data were added by my random daemon. Hooray for good luck in a long ago decision.

In any case, I don't use the device anymore.

Problems emerge for a unified /dev/*random

Posted Mar 30, 2022 12:39 UTC (Wed) by ncm (guest, #165) [Link]

Nowadays most devices come with a hardware random number generating device attached, typically a camera, radio, or microphone. The low bits of analog-to-digital converters provide a copious supply of entropy that the upper bits, howsoever predictable, cannot steal away.

Such devices might be more trustworthy than the "hardware RNG" instructions provided on processor cores, which we have seen demonstrated (in a recent AMD erratum) may be reliably turned off from microcode, and, we may presume, from an appropriate not-publicly-documented instruction sequence. Whether to try to defend against such an attack depends on your threat model, of course; if so, an unreliable source of random numbers might be the least of your problems. But defense in depth has rarely been a mistake.