Csdrhrt

Sophie Chen at Wired Magazine;

quantum mechanics could solve cryptography's random number problem

Such machine already exist, but it's too huge and not so fast in order to use it all the time.

Anyway, can it solve the problems connected to randomization and security or it will be still vulnerable?

The title of this article is complete hype. Tip: when a journalist says “X could solve Y”, read “X probably won't solve Y”. Much of the content of the article is hype too.

Cryptography has a random number problem, but the problem is not producing random numbers, and the proposal in this article wouldn't be useful to produce random numbers anyway.

Cryptography does need random numbers for many things. The problem of obtaining random numbers can be divided into three parts: generating sufficient entropy for security, generating a sufficient quantity and quality random numbers for the applications, and actually bringing the random data where it's needed. The first problem is solvable, the second is solved, the third one is where the difficulty is.

To generate random numbers, it's necessary to have a source of non-determinism. A deterministic computer, by definition, is incapable of producing anything random. But there is no need for any expensive machine using quantum mechanics. Classical mechanics or cheap applications of quantum mechanics are good enough in practice. Your PC has a random number generator, if it isn't an antique. Your phone probably has one too, if it's a not-too-old smartphone. If your credit card has a chip, it has a hardware random generator. You can find microcontrollers that cost a few cents (I'm talking bulk prices here) that have a built-in RNG. Many devices lack one (your home router might not have one), but at current prices it's a supply chain and requirements problem, not a cost problem. If you can control how a device is designed, there's no excuse not to include a hardware random generator.

A hardware random generator gives you entropy, but it isn't directly usable for cryptography. It usually has limited bandwidth and biases (no measurement apparatus is perfect). Fortunately, turning an entropy source into a cryptography-grade random generator is a solved problem. All you need to do is to use the entropy source to seed a pseudorandom generator. Any cryptography library has one or more PRNG available.

The real problem with random numbers in practice is getting all the software out there to use them correctly. This is a difficult problem to solve because every piece of software needs to get things right: properly relay the data, don't leave a copy lying around. The operating system driver needs to get it right, the system installer needs to get it right, all the layers of software libraries need to get it right, and the application needs to use the libraries properly. Proper use of randomness is near-impossible to test, so bugs are difficult to detect. Common problems include developers using non-cryptographic random generators when they need cryptographic ones (don't use rand anywhere near cryptographic code!), using a cryptographic PRNG that is not seeded properly (always use your OS's randomness source such as /dev/urandom or CryptGenRandom), using non-random inputs to functions where random input was needed, and systems where the entropy source is not configured properly.

So when the article says

Eventually, it would be great if they shrank the setup to fit on a chip, says Bierhorst: a random number generator in every laptop, so that nobody ever uses those algorithm-based numbers for encryption again.

that's attacking the part of the problem that doesn't need new technology. The reason people use “algorithm-based numbers for encryption” is that either their device lacks a generator which can be built cheaply using current technology, or that there's a problem in the software. This new machine would not help with either part of the problem.

As for the proposed application of a “randomness beacon”, it's a plausible one, but it's of limited use and difficult to put to practice. A randomness beacon, as the article explains, is useless for most cryptographic applications since it wouldn't be secret. It's useful as an impartial arbiter, for example to assign auditors to auditees, but that can be done with any source of randomness. The fact that the machine itself is more difficult to “hack” than a PC with RDRAND is not all that useful, because the hacking could be done in the reporting and logging system.

Sophie's comment regarding size and speed wasn't correct. Not all true random number generators are huge or slow. A very small and fast example is the following Swiss chip (in the tweezers):-

It outputs ~5 Mbps of true random numbers generated by a quantum photon counting process, whilst consuming less than 0.1W of power. There are more details available here, including use cases and a brochure.

Uncharacteristically, Wired has produced quite a bad article for a piece of technology. Sophie has focused on the number generation rate, not realising that the machine is not primarily a random number generator. Journalistic licence?

The official paper for the machine and experiment is here. It was built to test the Bell Inequality, and to disprove local realism that might have underpinned quantum mechanics. The size of the machine is necessary to ensure that the pairs of measurements are made outside of their respective light cones. That's the reason for the device's two ~130m legs.The random numbers popping out are just the experimental byproduct put to use via the randomness beacon.

The experiment was successful and local realism has been disproved, thereby supporting Spooky Action paradigms.

Well, I don't think that it can eliminate vulnerability cause it's still new technology that encounter many bugs.
Both the secret-key and public-key methods of cryptology have unique flaws. Oddly enough, quantum physics can be used to either solve or expand these flaws.

The problem with public-key cryptology is that it's based on the staggering size of the numbers created by the combination of the key and the algorithm used to encode the message.