# Cryptography's random number problem?

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?

• What's the problem supposedly being solved? – Maeher Dec 12 '18 at 16:16
• Welcome to crypto.se - Here is some advice to help you get an answer for your question: What is cryptography's random number problem? What machines are you referring to? TRNGs based on quantum effects can be the size of regular computer hardware. We can't answer "Can it solve the problems connected to randomization and security" without knowing what "it" is and what problems you are referring to. – Ella Rose Dec 12 '18 at 16:20
• also, “who” says this? the quote source would help with context – b degnan Dec 12 '18 at 16:20
• Please note that it is somewhat disingenuous to point to those attacks to show that there is a problem. Those attacks on RSA key pair generation were possible because there was no random source present, or that it was badly handled in software. Both of those issues can be solved without the device in question. – Maarten - reinstate Monica Dec 13 '18 at 21:34
• I dont think that this is a problem – Jane Air Jan 29 at 13:42

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.

• An additional major problem with hardware random number generators is that they are often very difficult to audit, a hardware source of entropy followed by a hardware whitener (Intel I3/5/7 for example) is indistinguishable from say AES128 in CTR mode unless you know the key to that AES implementation. Because of this you can never be sure that that nice hardware is actually giving you random and not something that collapses if you are the agency that created the key. In this respect a hash of a frame from a webcam or the low bit of the audio sample is probably at least easier to audit. – Dan Mills Dec 12 '18 at 23:34
• @DanMills You can't audit an RNG as a black box. The right way to design an RNG is to give software access to the unwhitened source, and to give auditors full access to both the hardware design and the software design (and manufacturing!). You also need to give the software access to the unwhitened source so that it can detect telltale patterns of bad environment conditions that cause the source to have less entropy than it should. – Gilles 'SO- stop being evil' Dec 12 '18 at 23:41
• Yep, which is exactly what Intel didn't do! The point about manufacturing is also very much on point, easy to diddle a metal layer so that your noise diode is short circuited.... the unwhitened source is what the low bit of a 24 bit microphone ADC or ADC connected to a warm resistor is, and at least in the resistor case that is a quantum source (Boltzmann noise). The trap there of course is that small signal analogue is easy to interfere with and computers have lots of things that might couple enough to correlate if the design is not spot on. – Dan Mills Dec 12 '18 at 23:57
• @DanMills Do you know of dopant-level hardware trojans? See §3.2 especially. Uber sneaky. – Paul Uszak Dec 13 '18 at 0:04
• @PaulUszak The problem with the dopant level hardware trojans is that the masks extract from the device layers. We check the generated masks against our masters as standard practice. The conversation wasn't really done by knowledgeable IC people. Firstly, they were using MAGIC, which will let you make those errors. Secondly, I cannot chose doping on any process < 32nm. I can chose ion implants in the channels. Even if you used this technique on 350nm, my post extraction tools would catch it. – b degnan Dec 13 '18 at 2:44

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.

• A brochure about the (genuinely interesting) IC is linked there, as well as a use case. Security theater does not care if this application uses an earlier device, since both are quantum; nor about the true security ultimately relying on the post conditioning. – fgrieu Dec 13 '18 at 5:21
• An interesting chip but are they about to solder it on that surface mount switch? what does the chip do, smash its head against whatever is bellow it when it want to output a 1? – daniel Dec 13 '18 at 11:11
• @daniel I'm sure the first chip is used to output the zero's and the other one is to output the ones... – Maarten - reinstate Monica Dec 13 '18 at 21:16
• @MaartenBodewes They both output only zeros. They're just really random zeros! – forest Dec 14 '18 at 2:51

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.

• The article describes a machine that generates provably random numbers. Your claim about the problem with public-key crypology (do you mean cryptography?) appears to miss the point. These algorithms also rely on the numbers being random, and this is pointed out in the article. – ChrisInEdmonton Dec 13 '18 at 14:43
• Yes, it's new, but it is believed to generate more random numbers. All the other stuff seems to be not very reliable in comparison with it. I'm not really an expert in this sphere, just learning, but still I'm almost sure it's like that. – Dumple Dec 13 '18 at 17:55
• You may want to edit your question to more directly and obviously address the question which reads "can [this quantum random number generator] solve [..] problems connected to randomization and security or [will it] be still vulnerable?" because right now it reads as an answer to thhe question "why is public and secret key crypto secure (or not)". – SEJPM Dec 13 '18 at 19:39
• @ChrisInEdmonton the term "cryptography" is nowadays used as the generic term. But "cryptology" is correct and arguably the better term (cryptography was specific to encryption / decryption). Otherwise I whole-heartily agree with your comment. – Maarten - reinstate Monica Dec 15 '18 at 13:01