I don't know if things are improved, but the last time I looked into HW random number generators, it was RS-232 connected ones, and the quality control was terrible a fairly high percentage of them generated very low quality random numbers. You would think you could mitigate this by xoring two of them together, but this made things much worse since 2 connected to the same outlet tended to be somewhat correlated!
My impression of the HW random number generator industry was that it was all snake oil, only the people selling them didn't necessarily know that was true.
[edit]
The technical section of the webpage[1] directly addresses most of the problems that the RS-232 devices I looked into a number of years ago had; namely it detects when the diodes are going bad, and tries to not exceed the estimated entropy rate (the RS-232 devices just blindly XORed them together at a predefined bitrate; boxes typically had 4 diodes, since 1 or more was bad in almost all shipping boxes). My experience was so bad with those devices though that I would want to spend a lot of time with any HW device before trusting it.
It is incredibly hard to make a really good random number generator in hardware. The best I've ever managed to come up with was also a diode based white noise generator with a PIC chip to digitize the output of the diode after amplification.
One of the problems of that approach is the low quality of the built in A/D converter of the PIC, another the ease with which powerline hum and other electromagnetic noise made it into the circuitry. We did get the circuit to work, but it was hard to duplicate with lots of fiddling required before we had a series of 4 of them good enough for production use.
A typical test run would take a week and it was not rare to see 'good' performance on a test run of a day while still having to discard components after a week.
Good tests for randomness will pick that out relatively easily.
There is a whole set of tests that you can run to determine the quality of your random data, hashing functions applied to the output of a less than perfect RNG will only fool the most naive of such tests.
Of course it all depends on the quality desired, in my case I had to satisfy all those tests and it was surprisingly hard to do, it's one of the few contracting jobs that I ever landed fixed price that I actually lost money on, the upside is that I learned an awful lot, especially about PCB layout, ground planes, power supply stabilization and semiconductor behaviour as well as analyzing such a system over an extended period.
It's the weirdest thing to be able to graph a perfect sinewave extrapolated from long term analysis of the summation of a few billion samples when looking for 50 or 100 Hz influences, especially if those samples pass most tests for randomness with flying colours. Circuits containing both analog and digital components are a black art, and my hat is definitely off to those that do this for a living and have turned it in to a science. Dabblers like me would do better to know the limits of their knowledge, I did eventually get it to work but if such a job came my way again I'd decline in spite of knowing more now about the subject than back then when I first took that job.
My impression of the HW random number generator industry was that it was all snake oil, only the people selling them didn't necessarily know that was true.
In general I find that snake oil salesmen don't realize that they're snake oil salesmen.
You would think you could mitigate this by xoring two of them together, but this made things much worse since 2 connected to the same outlet tended to be somewhat correlated!
I would collect the bit stream then run the result through SHA256 in 256 bit batches.
The best part of testing random number generators is playing 200,000 games of craps. My boss protested, but I just questioned his commitment to security…
High volume SSL/SSH traffic. Systems can be configured to fall back to insecure random number generator under load but it creates an attack vector where you intentionally DoS a system, then have more leverage to crack the encryption based on the weak(read predictable) random data the encryption is based on. The practicality of such an attack is beyond my knowledge.
Yes, it can be. In addition to a security issue making timing attacks more practical if an attacker knows they can deplete the entropy pool in a repeatable fashion.
In the past, I used random numbers from: http://www.fourmilab.ch/hotbits/
sourced from radioactive decay. The only issue I could see was the daily limit, but I only needed several kilobytes of randomness at any one time.
This is silly. The whole reason that cryptographic random number generators exist is to avoid the need for lots of entropy. You can start from 80 bits and "bootstrap" it to whatever quantity of random bits you need (and the seed entropy needed is available from /dev/random). PRNGs come with the guarantee that telling the difference from "true" random numbers is a hard problem.
You might claim that the hardness guarantees of PRNGs are not enough for you -- they are based on some assumptions after all -- but that is a specious objection, because those are the same assumptions that underlie all of digital security and e-commerce.
what are these guarantees you refer to? most pass a battery of tests e.g., diehard:
http://www.stat.fsu.edu/pub/diehard/
but if you give a PRNG x bits of entropy, then it can produce at most x bits of entropy over its entire output.
all PRNGs have cycles: that is, they'll produce random numbers x[1], x[2], ... , x[n], then random number x[n+1] = x[1], x[n+2] = x[2], .... often n isn't as big as you'd like, and sometimes there are correlations among x[i] and x[i+k] you really don't want (linear congruent generators have this problem).
the PRNG is a deterministic function of its seed. the hash is a deterministic function of the output. if you do the math and calculate the entropy (this isn't hard) you'll see that the total entropy is still 80 bits because the distributions of the PRNG output given the seed, and of the hash given the output have no entropy. the marginal entropy of the PRNG is 80 bits if you don't observe the seed.
Did you misread my statement as saying hashing the output will magically give another 80 bits of entropy? No, I'm saying to get another 80 bits before your PRNG repeats. I know you can infer things like linear congruential generators. I implemented such an inference program in grad school from someone else's thesis, then demoed it on a crypto USENET newsgroup. The hash is going to make inferring the seed much harder. Using a cryptographic PRNG will make even the unhashed output hard to infer. Using both is going to be way beyond the ability of most attackers.
why hash the output then? this is introducing a dependence in the PRNG that you seem not to need (nor want).
if you're going to generate another 80 bits of entropy, then simply use this as the seed for another PRNG. this, sure, i agree, will get you more entropy, because you're adding more entropy to the system from an external source (such as the advertised device).
It doesn't work like that. If you use this to create, say, a cryptographic key, you can break it if you can bruteforce an 80-bit key; depending on the specific application, you may need much less (e.g. if you can perform a birthday attack, you only need 2^40 tries).
I think the main advantage is that this RNG gives you the same results as a crypto-strong PRNG, but much faster. That said, I didn't see any benchmarks on their site.
Quantity 1 £36.00 with plenty of quantity discounts. Might be just the thing to make sure your VMs have enough entropy (I've read this can be an issue when they start up).
If I understand both correctly, the Quantis one generates a random number that didn't exist before generation due to quantum measurement principles, whereas the Simtec one uses a high noise environment in which the number does exist before measurement.
You're repeating nonsensical marketspeak. What does "a number that didn't exist before ..." even mean? And what does "quantum measurement principles" mean? I'll tell you: it means diddly squat.
The device the article is about measures electron flow through an electronic component through which 'usually' no electrons flow. That electrons flow in this device, is because they tunnel through the potential barrier. That's a quantum effect if there ever was one.
Converting the presence of electron flow into a number means you construct these numbers on the fly. The numbers did not 'exist before', for any reasonable meaning of that term.
Acutally, Simtec states: "each 256 bit block of data handed to the host was formed from somewhere in the region of 3840 bits read from the quantum generators."
Yes, you can buy "quantum generators" for only £36!
Seriously though, the noise that Simtec is measuring is unpredictable and based on a quantum process (electron tunnelling.)
One of their prime arguments is about the 4KB bucket available for random numbers on a standard Linux installation. Couldn't/Shouldn't that be raised to 1MB or so for server installations and that would solve the bandwidth problem if not the randomness problem?
That is a recognised method but it does have it's own failings. Certainly in server rooms although it seems noisy to us there are patterns that can still be generated.
Another similar method is to take static from radio waves. While random it's unfortunately hackable by someone who has a radio transmitter and can get close enough to your antenna (the same can be done with the microphone).
I worked at a poker startup and sourcing random numbers is both a political and mathematical nightmare.
Add another noisemaker with a chaotic component, like a Pacinko ball game with an automatic ball feed. Hashing the output will obliterate the patterns.
Considering the ultimate doom of the universe is very possibly infinite entropy, sometimes it bemuses me on a philosophical level that we try so hard to accelerate the process.
The only thing that I could come up with for 'infinite entropy' in Google was a piece about how 'big bangs' start from nothingness in empty space when the Universe 'cools off' or becomes 'too thin.' In that case, it seems like infinite entropy isn't necessarily the 'doom' of the Universe.
It is in the sense that nothing will be left, and the space-wide temperature will be arbitrarily close to zero K
I mean, the Universe wouldn't vanish or explode. We'd just all be dead, and it'd stop being interesting, the same way your magnesium strip is pretty boring and useless once it's finished burning.
I'm all for protecting our children from the harmful effects of entropy, but not our children's children because I don't think that kids should be having sex.
> "...it has a pair of devices that are wired up in such a way that as a high potential is applied across them, where electrons do not normally flow in this direction and would be blocked, the high voltage compresses the semiconduction gap sufficiently that the occasional stray electron will quantum tunnel through the P-N junction. (This is sometimes referred to as avalanche noise.) When this happens is unpredictable, and this is what the Entropy Key measures."
My impression of the HW random number generator industry was that it was all snake oil, only the people selling them didn't necessarily know that was true.
Se also: http://web.archive.org/web/20011027002011/http://dilbert.com...
[edit] The technical section of the webpage[1] directly addresses most of the problems that the RS-232 devices I looked into a number of years ago had; namely it detects when the diodes are going bad, and tries to not exceed the estimated entropy rate (the RS-232 devices just blindly XORed them together at a predefined bitrate; boxes typically had 4 diodes, since 1 or more was bad in almost all shipping boxes). My experience was so bad with those devices though that I would want to spend a lot of time with any HW device before trusting it.
1) http://www.entropykey.co.uk/tech/