Web server offers true random numbers via fluctuations of the quantum vacuum
jwz.org
jwz.org
You do not need exotic hardware to collect entropy to generate crypto keys. You need a correctly designed cryptographically secure PRNG which has had time to accumulate 100 or so bits of entropy (i.e., unknowability to the attacker). It's nice if it can be freshened every now and then with more entropy, but that really only should make a difference if you lose a backup tape and by some miracle the private key wasn't on there already. After it's warmed up, it should never need to block due to 'depleted entropy'. No one has ever broken such a CSPRNG. This is how the OpenSSL, OpenBSD, and FreeBSD /dev/randoms work.
On the other hand, what does tend to get broken regularly are overcomplicated and overengineered RNGs like this beast.
The one on the new Intel chips is handy, but it's largely overkill. We only need 100 bits now and then, not a steady rate at Gb/s (which can shut off abruptly when an attacker sharing your cloud hardware node decides to starve you of them). It's also not something that we can review for backdoors, so we should be reluctant to use it as the sole source of entropy.
A quantum vacuum random server is great like the way an internet-connected coffee pot is great. Fun, but not useful in production.
"/dev/random vs /dev/urandom" http://www.onkarjoshi.com/blog/191/device-dev-random-vs-uran...
/dev/random is hardware entropy dependent, and if application users use it too much (and we all know that many application developers don't do what's minimal stress for hardware or what's optimal "I just make it fast, it works for me"), every such application can block too often. Especially servers are problematic because you can't accumulate the entropy by measuring keyboard or whatever. That's why Intel made RdRand. And their competitors made some similar solutions even before that.
Good detailed discussion also on: http://en.wikipedia.org/wiki//dev/random
In short, hardware RNG in the CPU is a very good thing.
Of course, whoever doesn't need cryptographically secure randomness should anyway just use plain old pure software pseudorandom number generator:
OpenSSL, OpenBSD, and FreeBSD agree with me.
If you don't have a TPM, you can get one of these usb sticks: http://www.entropykey.co.uk/ and it will also feed /dev/random with large amounts of real random data.
It is possible to provide true randomness from a chip, but it's probably cheaper not to.
http://spectrum.ieee.org/semiconductors/processors/behind-in...
http://en.wikipedia.orghwiki/RdRand
I suspect they just didn't consider RNG quality as a big factor in the usefulness of the design. TPM pre-dates the recent advances in on-die TRNG design. Plus the chip tends to live on a low-speed bus on the system which makes it inherently a bit crappy as a place to keep a high-bandwidth application like an RNG.
Personally I'd trust the random data supplied by a third party web service less than the pseudo-random data that the software on my local machine produces. Especially if you mix in data from a TPM, especially if you mix in data from an Entropy Key as well.
And truly random string is such string, that there's no possible program producing this string as output, that is shorter than the string.
On deterministic computers you can only produce pseudorandom numbers, with varying quality of randomness, depending on generator program you use, but it's sometimes not enough (esp. in cryptography).
When something is deterministic, it is reproducible and therefore not good for creating crypto keys.
Most /dev/random implementations use data from the ethernet driver, the keyboard, mouse etc to get some input which isn't easy to reproduce.
The typical thing people do to get large amounts of randomness is to first generate some "real" random noise from some source (hardware thingamajigs, network timings, user interactions) and extrapolate these into longer sequences of random-looking numbers. The extrapolation can be fast and simple (in which case the randomness is not so good), or it can be slow and complex (to get decent looking randomness).
Hardware RNGs sometimes rely on thermal noise (which is really random) but there are sometimes flaws with how that noise is sampled and de-skewed. Also, they need to be monitored to cope with hardware failure. Be aware, especially if you're using them for cryptography, that they might be a poor fit for your purpose.
Testing Hardware RNGs
(http://www.robertnz.net/true_rng.html)
EDIT:
Descriptions of various forms of noise:
(http://www.eie.polyu.edu.hk/~ensurya/lect_notes/commun_cir/C...)
And surely everyone on HN knows that part of the "snow" noise displayed on an untuned TV is cosmic background radiation, ie "afterglow" of the big bang. I still find that amazing.
Many naive hardware based random number generators suffer from being not as random as one might think - thanks to quantising levels in A/D converters, to supposedly random physical processes having "spectra" where measurable signal occurs more in some bands than others, and to a multitude of other odd little effects just making a hardware based RNG is as simple as it seems.
The entropy key cited above has multiple noise sources and PRNG processes that mix them up and running checks to see that things are working as expected. That level of paranoid checking is more or less the minimum level required in a RNG to be confident about it.
The laptop was relatively idle when the test was being run.
It's worth noting that when you do a --gen-key it does output the message:
"We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilise the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy."
I can't imagine it would state that if "5 seconds" was anything like normal. Perhaps you have some sort of additional source of entropy which you don't know about.
How do you determine that on Linux?
The main article is just to appreciate the pure awesomeness of us being able to actually see something that's a result of quantum fluctuations! In vacuum!
http://www.fourmilab.ch/hotbits/
The site contains some interesting discussion around randomness and how their service works.
update - similar article (free) from same people http://www.opticsinfobase.org/view_article.cfm?gotourl=http%... (source http://www.opticsinfobase.org/oe/abstract.cfm?uri=oe-19-21-2... )
[it seems like this is actually a big deal - they are getting huge throughput]
- Get a high res webcam - Open it up and remove the filters. - Hook up the device. - From time to time you'll see random white dots appear.
There you have your ultra cheap random number generator. Works best in high radiation environments.
It would seem that this method would be muchmore expensive and time consuming than a simple web query. How precisely would this save me money?
It's under your control. There's no chance of an attacker serving you skewed numbers, or of MITM, or etc etc.
That may be important. (Cryptography, for example.)
Some people don't care, they just need some random numbers. People doing modelling like a lot of random numbers that are random enough, but they don't care if that same set of numbers is available elsewhere, or if it's easily repeatable.
Look into LavaRnd [1][2][3][4].
[1] What is LavaRnd? http://www.lavarnd.org/what/index.html
[2] LavaRnd Process in Detail: http://www.lavarnd.org/what/process.html
[3] Construction of a LavaCan: http://www.lavarnd.org/what/can-details.html
[4] Source code (open source): http://www.lavarnd.org/download/index.html
Since we have millions of transistors in our systems couldn't they (their collectors) be used to generate "truly" random numbers?