# Truly Random Numbers at Scale - Overloaded memory chips generate truly random numbers for encryption

For years, truly random numbers at scale has been elusive. Thus I read this recent research https://www.newscientist.com/article/2303984-overloaded-memory-chips-generate-truly-random-numbers-for-encryption/ and https://cacm.acm.org/news/257835-overloaded-memory-chips-generate-truly-random-numbers-for-encryption with great intrigue, anticipation and excitement.

My first question: What are the difficulties associated with generating true random numbers? Cost, practicalities such as power consumption?

Second question: What and who can be an arbiter on true randomness? i.e., who decides this particular number is truly randomly generated?

• The RDSEED instruction can be found on any recent x64 microprocessor. See en.wikipedia.org/wiki/RDRAND Also, ARM chips usually have similar capabilities, but it has not been standardized. Jan 24 at 9:04
• alright thats cool to know! why aren't people leveraging that since it is widely available? Jan 25 at 14:40
• They do. The Linux CSPRNG (/dev/urandom and /dev/random) uses it (among other sources) when available. It is assumed Windows does so too, but since it's closed source, this information is not public. Jan 25 at 14:50

For years, truly random numbers at scale has been elusive.

No, this is 100% hype. Generating random numbers is easy. There are plenty of known techniques to do it. “Scale” is not a problem with respect to the quantity of random numbers, because “true” randomness is only needed so seed a cryptographically secure pseudorandom generator (CSPRNG). The output of a CSPRNG is indistinguishable from true random.

My first question: What are the difficulties associated with generating true random numbers? Cost, practicalities such as power consumption?

One difficulty with random generation is that it requires dedicated hardware which costs a significant fraction of a cent to mass-produce. This is a concern for devices whose price is of the order of magnitude of a cent per unit. This difficulty is largely solved nowadays: price have come down compared to a decade or so ago, and many cheap microcontrollers include a TRNG.

Incidentally, generating random numbers through processor and memory jitter is a well-known technique which cannot be employed in very cheap devices because they're too slow and stable. And it's not a very useful technique on larger devices because for those the incremental cost of a dedicated TRNG is negligible. All modern PC and smartphone processors include a dedicated TRNG, for example.

Power consumption is not much of an issue since the TRNG only needs to run for a very short amount of time. Latency can be an issue when the processor boots.

As a designer of embedded systems who doesn't know much about how the hardware works (my work is firmly at the software and system levels), the improvements I'd like to see in hardware random generation are to be cheaper to mass-produce (so that they're in every device), to have less latency and to be more reliable to environmental perturbations (e.g. temperature and power variations).

But in practice, the biggest problem with random generation is not in the hardware. It's in the software ecosystem which has trouble bridging all the steps between the hardware design and the application design. The problem is the operating systems and programming language interfaces where getting insecure random numbers is easy but getting secure random numbers is hard. The problem is misconfigured systems and applications that pass functional tests but have not had a proper security review.

Second question: What and who can be an arbiter on true randomness? i.e., who decides this particular number is truly randomly generated?

Since you can't tell how random a number is by looking at the number, you have to look at the process by which the number is generated.

• "randomness is only needed to seed a ... (CSPRNG)... CSPRNG is indistinguishable from true random" Don't agree with that. A sequence of independent random variables according to the mathematical definition meets a stream cipher, which is preserving input information; this cannot be reached with a seed shorter than the output vector. Feb 9 at 10:43
• @SamGinrich This site is about cryptography. I meant indistinguishable to an adversary with realistic computing power, not mathematically indistiguishable. Feb 9 at 10:48
• Sure, I understand "indistinguisable". Think there is no need to allocate "true random", which a stream cipher actually is in contrast to a state machine, realizing a seeded random algorithm. Feb 9 at 10:53
1. The main difficulty is to find a good source of entropy. It is a measure of "randomness". Well, if we have a value $$seed$$ such that $$H(seed)=n$$, we cannot produce a sequence $$x, |x|\geq|seed|$$ with greater entropy, i.e. $$\forall x : x=f(seed)\land|x|\geq|seed|\implies H(x)\leq H(seed)$$, where $$f$$ is some deterministic algorithm (PRNG). Entropy is defined as follows: $$H(X)=-\sum_{x\ \in\ \text{Dom}(X)}\text{Pr}(x)\cdot\text{log}_2\text{Pr}(x)$$ where $$X$$ is a random variable. <removed>
In other words in the best case we get a longer sequence with the same amount of "randomness" in it as in the shortest one. There's no way to generate a potentially unbounded truly random sequence using some algorithm from a finite sequence without any additional entropy source.
UPD: it's not quite correct to use the formula for sequences. But the sense of this paragraph remains valid: you cannot create "randomness" from nothing.

2. Well, that's a good question, because we can say, that whether some sequence is random or not with a certain probability. The only way is to use statistical tests. An ideal (or truly) random sequence is defined as follows: $$X_\to=\{\zeta_1, \zeta_2, ..., \zeta_n,...\}$$ where $$\zeta_i, i\in\{1,2,...\}$$ are uniformly distributed on some set $$X$$ random variables and in each subset $$\{\zeta_{i_1},...,\zeta_{i_k}\}$$ all variables are independent. Having an arbitrary sequence the only we can do is to test its statistical properties and to say that with a high (or low) probability these requirements hold for these variables <redacted to make it more clear>.
<removed>
In all articles I've read about truly random generators are tested statistically. Unfortunately I can't read article, that you mentioned in the question, but I think, that there will be the same sort of research.

Well, I suppose, that there could be a potential method to prove, that some generator produces a sequence with the maximum possible entropy, but I haven't seen it yet. But maybe it's impossible to have such method. If there's one, I'm interested to read about it :)

UPD: maximum entropy isn't required for true randomness. Here is some citations of @Paul Uszak:

Such a sequence [truly random] only needs a monotonically increasing amount of Kolmogorov complexity. Bias/correlation is irrelevant.

TRNGs aren’t tested for true randomness. Their ‘truth’ comes from an understanding of the non deterministic physical processes that create the output Kolmogorov complexity.

UPD: in a nutshell: TRNGs use some physical unpredictable events to yield a sequence, PRNGs use computer algorithms.

• Hi, but some issues. 0) There are no sources of entropy outwith thermodynamics. Cryptographic entropy is only created by the observer during sampling. 1) The Shannon formula only applies to IID data, and doesn't apply in the general case of entropy source sampling. 2) Statistical tests only test for uniformity and independence downstream of the randomness extractor. No test can differentiate between a TRNG and an RNG. dieharder will pass the Mersenne Twister, and ent and FIPS 140 pass any .7z archive. Jan 23 at 14:24
• 3) Maximum possible entropy isn't required for a truly random sequence. Such a sequence only needs a monotonically increasing amount of Kolmogorov complexity. Bias/correlation is irrelevant. 4) TRNGs aren’t tested for true randomness. Their ‘truth’ comes from an understanding of the non deterministic physical processes that create the output Kolmogorov complexity. Jan 23 at 14:25

What are the difficulties associated with generating true random numbers?

There are no tangible difficulties with generating shed loads of true random numbers. The Haveged daemon claims to generate megabits/s of true entropy without any external hardware. I’m not sure what ‘at scale’ realistically means though. Cycling an AES key per every minute is a Kolmogorov rate of <3 bits/s. With respect, that’s child’s play even for DIYers. Look at those night time party pics on your smartphone and wonder what all that image noise is. If you have ~3000 Euros you can buy a 240 Mbps TRNG that uses beam splitting technology. If your life depended on it, is \$2600 too much? And the yeolde /dev/random would do >30 kB/hr just checking email. Double that if you're researching PornHub.

The most likely intangible reason I mustn’t go into is reflected in the following; Athletes are being advised to use burner phones in Beijing.

What and who can be an arbiter on true randomness?

Only you.

There’s a very famous web site strap line that says ”Secure entropy? Your entropy.” The concept of computational indistinguishability means that the output of the Mersenne Twister looks pretty much like the output of /dev/random. This is the take away from here.

The Intel on-chip hardware random number generator looks random but nobody in the *nix community trusts it. And so they shouldn’t given the publicly confirmed NOBUS2 policy. And unfortunately for you/us it’s impossible to reverse engineer a multilayer silicon die with billions of transistors.

This part of my answer could go on for thousands of mouse downs, so I’ll end with trying to persuade you to build an entropy source yourself with a little diode (£2.08 + VAT/20).

2 Get a tin hat. The really thick Christmas turkey type. The NOBUS entry has been deleted from Wikipedia. Draw your own conclusions. So I direct you to the WAPO article with the head of the CIA/NSA (same guy).

• I never quite understood people that do not trust Intel's trng, but trust everything else Intel builds. If the NSA can persuade intel to put a backdoor in the trng, then they can also persuade them to build a CPU that detects when certain instruction sequences (such as a OpenSSL rng code) is running and deliberately misinterpret those instructions. Jan 25 at 3:40
• @poncho I'm one of these sceptics :) When it comes to security I don't care about performance: There is no NSA, no Windows, no Intel, no OpenSSL and no didactic people with the attitude "Never ever create security systems by your own" Feb 9 at 13:04
• @SamGinrich Hear, hear! What the prior commentator has not realised is that his criticism is illogical. We can satisfy ourselves that an Intel CPU is working correctly because it can be verified against it’s specification though testing. Testing by millions of users, in all countries, at all levels of technical competency. Computational indistinguishability mathematically rules out verifying that Intel’s alleged TRNG generates any Kolmogorov randomness at all. Further.... Feb 9 at 17:39
• @Paul Well, I do not oppose to poncho's comment: If you have a snake with two heads, it's not plausible to distrust one head and hope the other one won't bite you. Same, your monitoring attempt is fine; what you need to realize it, is an independent monitoring implementation, and without trust in corporations, e.g. which unfriended Mr. Snowden. Feb 9 at 18:02
• @poncho I think that's very unlikely. PoC||GTFO had a good article about how that could be done (in an emulator, at least), and it proved much more complicated and fragile than a backdoored TRNG that just combined a true 64-bit random number and a secret 128-bit backdoor value and used that as the seed. I think Paul's right to be skeptical of RDRAND/RDTSC.
– forest
May 14 at 1:02