| |||||||||||||
On the safety of Linux random numbersOn the safety of Linux random numbersPosted May 11, 2006 5:02 UTC (Thu) by Thalience (subscriber, #4217)Parent article: On the safety of Linux random numbers
It surprises me that more computers don't have hardware random number generators. At least "server class" hardware anyway.
Do USB interrupts have the right hooks to add entropy? Perhaps a simple device to send random USB HID events on a server could be developed.
(Log in to post comments)
Why not get randomness from sensors? Posted May 11, 2006 5:48 UTC (Thu) by Ross (subscriber, #4065) [Link] There are some untapped sources of entropy: the hardware sensors on most motherboards. The temperature, voltage, fan speed, etc. sensors could be manipulated by someone with physical access, but only to a limited precision. Doing some kind of differential sampling and not counting zero inputs as having any entropy should help.
Is there a reason the drivers for those devices don't contribute to the entropy pool?
Why not get randomness from sensors? Posted May 11, 2006 6:08 UTC (Thu) by jwb (guest, #15467) [Link] It is fantastically expensive to communicate with the most common sensor hardware. Often the system has to bang bits over a two-wire port. It is reasonable to access these devices once every second or so, but I doubt that you'd be able to sample them often enough to generate substantial entropy.
It would be nice if hardware entropy devices were more common. There are plenty of random processes out there in the electrical world, like shot noise.
Why not get randomness from sensors? Posted May 11, 2006 14:44 UTC (Thu) by pjones (subscriber, #31722) [Link] I think you're wrong about what "substantial" means here. It doesn't need to be enough entropy to use as the system's only source. It needs to be enough to pervert the data from all the other sources in a way that masks their (potential) weeknesses. That requires surprisingly little data, if it is truly unavailable to attackers.
To that end, the bigger worry here is that it's just the sort of data you might want to stick in SNMP for your monitoring infrastructure to check on.
Why not get randomness from sensors? Posted May 11, 2006 21:54 UTC (Thu) by giraffedata (subscriber, #1954) [Link] It doesn't need to be enough entropy to use as the system's only source. It needs to be enough to pervert the data from all the other sources in a way that masks their (potential) weeknesses. You seem to be describing a means of creating entropy out of nothing. If all the other sources provide 1000 bits per second of entropy and the hardware sensor gives you another 10 bits per second, you've got at most 1010 bits per second of entropy no matter what you do with those 10 new bits. So I think "substantial" is the same amount no matter how you look at it. Actually, I think the sensors mentioned have negligible entropy to contribute. You read them all digitally, and given one reading, you can predict very well what the reading will be a second later, to the full precision of the sensor.
Intel i8x0 Posted May 11, 2006 6:40 UTC (Thu) by ncm (subscriber, #165) [Link] As I understand it, Intel included an interface for getting efficient access to truly random numbers in their chipsets starting at i810 or so. In the early versions, this was a separate, optional chip wired to a dedicated pin. Of course few motherboard manufacturers left pads for it, and even fewer built boards with the chip present. The presence or absence of a random-number generator chip is not high on the list of motherboard features that early adopters (i.e. gamers) look for. Intel marketing must have interpreted this as an entire lack of interest among users, and so omitted the (very cheap!) feature as they integrated the various outboard chips.
So, it appears we can blame Intel marketing for sabotaging this solemnly promised feature of all future Intel chipsets. As promised, all are equipped to report whether they can produce random numbers; they all say "no".
(This is the best reconstruction of events I have been able to establish through Google searches. Someone else may have better information not readily googled. I welcome corrections.)
Hardware RNGs in chipsets and CPUs Posted May 11, 2006 14:48 UTC (Thu) by hmh (subscriber, #3838) [Link] It is more complicated than this. Intel placed the HRNG inside its FWH (firmware hub). I.e, inside a FLASH memory device that is supposed to host the BIOS. Were it inside the MCH (the north bridge), all machines would have it and this story could be very different indeed.
The Intel FWH HRNG is very slow, but it appears to be of very high quality... Unfortunately, the FWH was quickly made an *optional* component of the chipset for whichever reason, and that effectively killed the whole idea. Sometime after that, Intel declared the whole "more secure computers by using an Intel chipset with a HRNG" idea a bust and stopped even caring about producing FWHs with HRNGs.
After that blow, often not even Intel itself would uses their FWH. Take a Intel D875PBZ motherboard for example. I have one, and direct access to three others. Two of them have Intel FWHs, of which one has a working HRNG and the other does not (the HRNG is disabled on silicon). The two other boards use compatible FWHs from other chip manufacturers, that don't have a HRNG either.
Add to it that (AFAIK at least) MS Windows does not have a common interface to get the random numbers from (Unix is easy, provide them through /dev/u?random and everybody uses it), and nobody was really paying much attention to the Intel device driver required to get the data from the FWH...
Now, VIA did things almost right. They placed an *extremely* fast HRNG inside their Nehemia CPU cores (but last time I checked, you'd have to talk directly to them if you wanted to make sure a batch of Nehemia CPUs would come with enabled cores: they disabled the HRNGs when they failed the factory test, instead of scrapping the CPU), added a good hardware crypto engine, and made a major marketing party out of it. Not happy with just one, the newest VIA cores have two HRNGs in different areas of the chip... so you get double the bandwidth, and somewhat less correlation on the output stream.
A heavily modifed version of rng-tools got about 2Mbit/s of random bits from such a Nehemiah CPU (at its highest quality mode, at lowest quality, it is probably on the 12 Mbit/s range in a dual HRNG CPU). This work was sponsored by mekensleep.com, and is available in Debian experimental under the GPL license. One can also use Martin Peck's modified hw_random linux module if they prefer a kernelspace solution.
Intel i8x0 Posted May 11, 2006 21:42 UTC (Thu) by giraffedata (subscriber, #1954) [Link] Intel included an interface for getting efficient access to truly random numbers in their chipsets starting at i810 or so How does it generate truly random numbers?
Intel i8x0 Posted May 12, 2006 7:33 UTC (Fri) by ncm (subscriber, #165) [Link] How does it generate truly random numbers?Physics. There are plenty of ways to extract truly-random noise from the detailed behavior of electronic components. Generally these sort out into those that go below the statistical averaging of "electric current" to look at thermal variation of the motion of individual electrons ("shot noise"), and those that depend on quantum indeterminacy. Given random analog noise, whether as a current, voltage, or timing noise, it's not hard to turn it into unbiased numbers.
On the safety of Linux random numbers Posted May 11, 2006 7:17 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] you are forgetting that there is a huge number of embeded systems that are lacking external inputs (and drives in many cases), but still need entropy.
these are hardly 'server class' as I think you are defining it.
On the safety of Linux random numbers Posted May 11, 2006 17:11 UTC (Thu) by drosser (guest, #29597) [Link] Even the mighty Mainframe has had its share of comeuppances in regard to random numbers. And when you find a bug in hardware, it's really difficult and costly to fix.
|
|||||||||||||