Fixing getrandom()

Posted Sep 28, 2019 5:08 UTC (Sat) by ncm (guest, #165)
Parent article: Fixing getrandom()

I am always amazed when people insist that truly random data is a scarce resource. Most machines nowadays have at least one of a CCD camera, microphone, or radio reciever. All are excellent sources of enough truly random noise (along with possibly deterministic bits, which are harmless) for almost any purpose.

Fixing getrandom()

Posted Sep 28, 2019 6:00 UTC (Sat) by alonz (subscriber, #815) [Link]

The actual scarce resource (in my opinion 😏) is random data that can be trusted by a truly-paranoid person. (Whether the paranoia is justified or not is a different question; I would expect the smart paranoid to use a hardware RNG, not trust the off-the-shelf randomness from a general-purpose computer + OS).

For most uses, a simple userspace solution that runs very early in the boot sequence and credits some environment noise as entropy should be sufficient. This would solve even the “initial SSHD seed” concerns — however it is easily broken by distributors / packagers who might remove it in the name of “faster boot”.

Fixing getrandom()

Posted Sep 29, 2019 6:04 UTC (Sun) by edeloget (subscriber, #88392) [Link]

Well, for the past ten years I have been developing specialized distributions for network devices, and they tend to not have any of the above. And yes, SSH keys generated on the first boot are really a pain (actually less of a pain these days because newer CPUs tend to propose a hwrng but hey, this is an industry where you are routinely dealing with severly out-of-date CPUs...).

Fixing getrandom()

Posted Sep 30, 2019 8:26 UTC (Mon) by anton (subscriber, #25547) [Link] (3 responses)

I do not know if a microphone or radio are good random sources, but a camera is. The resolution of camera sensors is high enough that the randomness of the photons coming in is reflected in the raw sensor output (and it is a lot for a (not too) bright picture). However, that means that the sensor must be on and receive significant light on booting, and you need a way to get the raw data (transformation into JPEG usually tries to get rid of the noise that we want for the RNG).

Fixing getrandom()

Posted Sep 30, 2019 11:59 UTC (Mon) by excors (subscriber, #95769) [Link] (1 responses)

I think you can get a decent amount of entropy even if there is no light on the camera, because of thermal noise in the sensor. That's probably safer than receiving significant light, because if the sensor gets saturated then you'll get a pure white image with no entropy. Phone cameras don't have physical shutters but the sensors often have some non-exposed pixels around the edge (for black level calibration etc) and you could probably use those.

> you need a way to get the raw data (transformation into JPEG usually tries to get rid of the noise that we want for the RNG)

It's not just the JPEG compression - the Android camera API is happy to give you uncompressed YUV but that still wouldn't be raw enough. You'd want the (typically) 10-bit Bayer data directly from the sensor, before the ISP has tried to make it look pretty (doing noise reduction, adjusting levels in a way that might saturate the noise out of existence, smoothing the image, etc). And you probably want to manually configure the sensor to maximise noise (long exposure, high gain, disable binning, etc). Android provides enough control to let applications request that, but I don't know how many of the camera drivers implement it fully, so it's probably not a very portable approach.

Fixing getrandom()

Posted Sep 30, 2019 12:49 UTC (Mon) by anton (subscriber, #25547) [Link]

Thermal noise is relatively small compared to photon noise if the sensor receives significant photons, but may be enough for initializing the RNG. And of course you don't want to be have so much brightness and so much exposure that the sensor saturates, but you can recognize anything approaching saturation, and then use shorter exposure time, if too many pixels are saturated. Combining high gain with long exposure will give more thermal noise in darkness, but produce saturation if there is light.

Fixing getrandom()

Posted Oct 3, 2019 10:40 UTC (Thu) by NRArnot (subscriber, #3033) [Link]

As long as you can crank up the gain high enough to input "hiss" or "static" (electronic shot noise or cosmic background radiation) then even a microphone jack with no microphone plugged in, or a radio with no aerial, is a source of physical randomness. I don't know if the common on-board microphone sockets in the PC world can be used this way. I guess the problem for the truly paranoid, is how to tell whether what is coming in has been deviously compromised so as to only look random.

Personally I'd go with a boot parameter "paranoia = n" (maybe the current and maximum value is 11, with a nod to Spinal Tap). 10 would allow use of the random number generator on the CPU chip if there is one, and thereby solve all the problems other than the possibility that (insert conspiracy theory here).

Fixing getrandom()

Posted Nov 19, 2021 16:51 UTC (Fri) by Lawless-M (guest, #155377) [Link]

My VMs do not have cameras, radios or microphones