idquantique .vs. rdrand

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.