We are currently looking at using the idquantique random number generator device to provide random numbers. There are some issues though. We would only be using one device and we have at least 5 servers that would need to use it and this number will probably increase in the future. This implies that blocks of random numbers would have to be sent to the servers in some way. All the servers are running Linux.

All of our servers are Intel based and have the RDRand random number instruction available. It would be easier to use RDRand since no networking calls would need to be made and RDRand also appears to be significantly faster.

But, the question I would like answered is - is there a difference between the quality of the random numbers generated by RDRand and those generated by idquantique? Has anyone ever measured or tried to measure how well these two random number devices perform against each other?


About the only way to answer this is to ask who you trust more. IDQ makes the following statements.

from here.

Existing randomness sources can be grouped in two classes: software solutions, which can only generate pseudo-random bit streams, and physical sources. In the latter, most random generators rely on classical physics to produce what looks like a random stream of bits.

In reality, determinism is hidden behind complexity. Contrary to classical physics, quantum physics is fundamentally random. It is the only theory within the fabric of modern physics that integrates randomness.

If you trust IDQ's statements, then Intel's RdRand solution, being based in software using hardware entropy, is sub par. However, even that might be good enough depending upon your particular usage.

Next, I'm not entirely sure why you would only use 1 device to generate numbers for multiple servers. The quantis cards aren't terribly expensive. Further, if what you are doing requires that type of randomness then it stands to reason that the money spent for cards for each server would be trivial to what you are doing.

However, if not, then you might just punt on using quantis and go with the built in Intel solution.

  • 2
    The phrase "Quantum physics is fundamentally random" is provably false; anyone who has made a cursory examination of the Double-Slit experiment knows that. The process that the white paper illustrates for generating random numbers might itself be suitably random, but you can't generalize that to a statement about all of quantum physics. – Robert Harvey Feb 21 '13 at 19:12
  • All that said, the technique they employ is probably excellent at generating random numbers. Statistical analysis can be used to determine the overall quality of the numbers that any RNG generates. – Robert Harvey Feb 21 '13 at 19:13
  • 1
    @RobertHarvey Statistical analysis can only discover the most blatant flaws in a PRNG. There are plenty of flawed PRNGs that no statistical test will find. – CodesInChaos May 11 '13 at 17:51
  • @CodesInChaos: I'll grant you that. As I said, you can statistically analyze a sample of the numbers that a PRNG generates to evaluate their overall quality of randomness. – Robert Harvey May 11 '13 at 17:57

There is no software in Intel's random number generator. The point of an on chip hardware TRNG accessed through the instruction set is reduced attack surface and performance. Sending random numbers over the network for security purposes is frankly wrong.

  • While the Intel PRNG has no software part, RdRand is a PRNG seeded by a TRNG. Only RdSeed is a TRNG. – CodesInChaos May 11 '13 at 19:36

I certainly would go with Intel over IDQ.

Intel offers two different instructions:

  • RdSeed - Each output contains new hardware entropy of the requested size. Uses AES based post-processing. Similar to /dev/random
  • RdRand - Reuses exiting hardware entropy occasionally mixing in new one. Uses an AES based process to produce arbitrarily large outputs from the current pool. Similar to /dev/urandom except that /dev/urandom can sometimes be accessed before it has been properly seeded. That can't happen with RdRand.

Personally I'd seed a software PRNG with entropy obtained from RdSeed. But if you trust Intel you can use RdRand directly.

Obtaining randomness securely over a network is complex and it might go wrong in subtle ways. If you use IDQ use a separate device for each server.

There are also many myth surrounding random numbers, such as "exhausting entropy". In practice seeding a crypto PRNG once is enough. Once you seed them with sufficient entropy (at least 128 bits at the same time) they will produce practically unlimited amounts of pseudo random data. As long as the cryptographic primitive behind them remains unbroken, that pseudo random data is indistinguishable from real random data by an attacker with reasonable computational bounds.

There have been stories about /dev/urandom producing bad numbers, but all of them were related to outputting data before the PRNG was seeded with sufficient entropy.


Basically, yes. Software-based pseudo-random-number generators will always be inferior to true random-number generators that are based on observation of provably-random events. I think the real question, though, is do you need absolute randomness, or is RdRand "good enough"? If you're just generating random keys to ensure even distribution across a hash table or something similar, then you probably don't need absolute randomness.

  • What do you mean by "inferior?" – Robert Harvey Feb 21 '13 at 20:00
  • They're pseudo random number generators. They generate numbers using an algorithm, so they aren't truly random. And if you can set their internal state (using a seed value), they'll generate the same sequence every time. Jeff Atwood points out some of their shortcomings in this Coding Horror article – TMN Feb 22 '13 at 13:55
  • 1
    The coding horror article also points out the "inferiority" of such numbers, but does not describe what quality constitutes "better" random numbers, or even why such "goodness" is desirable. – Robert Harvey Feb 22 '13 at 15:17
  • 2
    If you take a proper PRNG and seed it with about 256 bits of hardware entropy it'll produce unlimited amounts of pseudo-random data that's completely indistinguishable from real data by any known process. – CodesInChaos May 11 '13 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.