> Don't we already have "true" random number generators embedded on most modern processors? I was under the impression most motherboards have some sensors strictly for this purpose--to read data from static or thermal sensors in order to add entropy to the pool.
Paranoid people might fear that those have been compromised à la Dual_EC_DRBG.
> Why not just use a hardware-backed random number generator?
They do, don't they? I think the Lavalamps, etc, are just _extra_ entropy. The more entropy you add (even if it's _not_ a certified or perfect random source) only improves the random number generator.
> I'd say that this isn't often done simply because computers didn't typically have a lot of sensors until recently
I thought it was done a lot, for example, in the Linux kernel: "The random number generator gathers environmental noise from device drivers and other sources into an entropy pool." [1]
> If you don't trust the hardware, then you've already lost, no matter what algorithmic construction you are using. How are you going to trust your random number generator if 1 + 1 = 2 except when it equals NSA?
You can verify the random number generator. If you know the algorithm and the seed values you can run it on multiple different platforms, or with a pen and paper and verify that the output is as expected and repeatable. If you have large amounts of entropy you are feeding into it, you can log it for testing purposes.
There are also apparently some EC based algorithms that can be used to fix or at lease reduce the impact of a compromised random number generator.
That might not protect against a active attack on your specific system by the NSA (they could send/embedded a magic packet that gives them total control over the CPU for example), might even be possible for it to happen on the NIC controller rather than the CPU if it has access to the system bus. At the least they could flip it into some kind of backdoor random number mode by embedding some extra data in a TLS handshake or whatever. But it should protect against widespread passive surveillance.
> Nevertheless, the output of the hardware RNGs provided by the Intel or AMD CPUs can be used in a reasonably secure way if the supposedly random values are never used directly, but they are passed through a cryptographic hash, e.g. SHA-256. Even SHA-1 is completely adequate for this special purpose
Why would you go to any of this trouble and not just XOR the output of RDRAND into the starting seed (based on hardware entropy) for your PRNG (/dev/urandom)? Even if it turns out that Intel is providing a single static value (like all zeros) to every device ever, that's not going to help them figure out the starting seed if the rest of the entropy is from a sufficiently secure source.
> Pretty much every chip has an RNG which can be as simple as just a single free running oscillator you sample
Every chip may have some sort of noise to sample, but they are nowhere near good sources of entropy.
Entropy is not a binary thing (you either have it or don't), it's a spectrum and entropy gathered on-die is poor entropy.
Look, I concede that my knowledge on this subject is a bit dated, but the last time I checked there were no good sources of entropy on-die for any chip in wide use. All cryptographically secure RNGs depend on a peripheral to grab noise from the environment to mix into the entropy pool.
A free-running oscillator is a very poor source of entropy.
> It's best to think of this as an OS/distro detail; if you can reasonably expect /dev/urandom to give you insecure bits, your distro has a vulnerability.
Isn't that more a function of hardware than software? The hardware random number generators on modern CPUs pretty much eliminate the need to worry about entropy...
>That said, I agree that you still shouldn't use it in a production environment!
I wonder though. There's a possibility that you'll screw something up and miss it during testing, but I've also seen some scary analyses of expensive off the shelf RNG hardware.
I'd say that if you're in a position of highly restricted capital that requires generation of tons and tons of secure random numbers, the ugly truth is that an open source DIY solution for generating your own entropy (especially if you can use multiple designs that are separately tested) might be safer than dumping your limited resources on proprietary unknowns.
> Also, usually HW RNGs include a firmware module that is constantly monitoring the entropy output and shutting off the generator in case of it sinking below a certain threshold to detect hardware failure and prevent it from causing predictable output.
This sentence reminded me of the recent revelation of some smartcards:
Afaik the failure was exactly that there was insufficient HW failure detection.
edit:
> Even worse, the firmware includes a line of code that ensures that the "RNG" never outputs the same "random" number twice in a row.
Also this reminds me of another anecdote. In math/stats class teacher told us of a experiment where two people were to write a 100 digit random sequence of 0s and 1s on a paper. One person was to use a coin flip, an the other was to just make the bits up. Then the person administering the experiment would take the sequences and guess which one was true random (coin flipped) and which one was human-generated. The trick being that humans tend to avoid repetition, and the one with (iirc) 6 consecutive 0s or 1s was most likely true random.
No, people don't directly fear it's backdoored by the NSA. There has never been any evidence that it's backdoored by the NSA. The algorithm it's documented as using (based on AES) is not the one that was backdoored by the NSA (Dual_EC_DRBG), though you would have to take a look at the chip with a scanning electron microscope in order to verify this.
The kernel developers just don't think it's a good idea to blindly trust unauditable hardware random number generators. Using it in conjunction with other sources of entropy is one thing; just using it on its own is putting a bit too much faith in it, especially because the code that uses it uses a generic wrapper for any hardware random number generation instruction, so if AMD or ARM or MIPS chips later come with random number generators, the kernel will be able to take advantage of their entropy without putting itself at risk if one of them is backdoored.
There's a difference between fearing that something is backdoored, and thinking that it's not a good policy not to blindly trust something.
That Intel is cooperating with the TLAs and providing a weak on-chip random number generator? Or a random number generator that can be made to be weak? Or what?
And how credible is the risk when that information is used to seed a pool of entropy, rather than being used raw?
> That's fine if you trust the PRNG. Linux used to at least attempt to provide a source of true randomness. You and Hendrikto are essentially asserting that everyone ought to accept the PRNG output in lieu of true randomness. Given various compromises in RNG primitives over the years, I'm not so sure it's a good idea to completely close off the true entropy estimation to userspace. I prefer punting that choice to applications, which can use urandom or random today at their choice.
Linux never provided a source of true randomness through /dev/random. The output of both /dev/random and /dev/urandom is from the same PRNG. The difference is that /dev/random would provide an estimate of the entropy that was input to the PRNG, and if the estimate was larger than the number of bits output, it would block.
> In particular, suppose you are administering a remote machine, so that you don’t have access to the USB ports or the audio ports. It is entirely possible that there is no good way to install sufficient randomness. You need to prevail upon whoever has access to the remote machine and get them to provide something, perhaps a random seed file, or a virtual /dev/hwrng, or a real hardware-based solution (using the audio system or otherwise). If they can’t or won’t do that, you can plan on being hacked.
This is especially true for embedded systems, that often cannot provide good randomness due to extreme adversarial settings.
Smart cards will have anti-tamper true-random number generators (random number generators that are hardware-based). And even that is shady.
> Except if /dev/urandom is using a hardware based random number generator, then you have to trust that the hardware hasn't received some NSA alterations at some point during the design.
That is a valid concern that needs to be part of your risk assessment. "Do I want to protect my secrets from a well funded government agency?"[1]
But there are other risks that need to be thought about too. Some people seem to think that hardware RNGs are better than software. Often they're not, they're lousy.
HWrngs can have subtle failure rates which are hard to detect.
Once you've done all the de-skewing and other checks they can be quite low bandwidth.
> You can use other things, like microphone input,
There's now been reported a way to hack a computer by way of its microphone, so that particular method is out.
> or CPU temperature.
CPU temperature doesn't change enough to serve as a secure source of entropy.
> No need to buy expensive hardware generators.
In fact, there are plenty of projects meant to locate sources of entropy to provide more randomness for computer security purposes. The idea of a hardware source like a reverse-biased diode is just one example.
> Then you can use something like Fortuna ...
Interestingly, the Fortuna scheme relies on system sources of entropy other than its own resources to assure security.
I've always wondered: why aren't ADCs (e.g. mic input) and temperature sensors considered a good source of entropy, particularly if the lower bits are taken?
So, would you be equally comfortable with stating that a hardware random generator doesn't solve any problems related to boot time entropy and the use of insecure RNGs by mistake?
> Would it be near-impossible to have a hardware-level RNG generator that spits out bits at a sufficient enough rate to avoid software-based RNG schemes?
Intel itself ships expensive accelerator cards that have "zero software" in key seed generation capable of generating multiple gigabytes per second of random bits.
Dumb question, why not have all processors contain a new hardware RNG based on thermal noise or some such thing? That was even VMs can get some stable entropy.
Paranoid people might fear that those have been compromised à la Dual_EC_DRBG.
reply