# Post processing method for True Random Number Generator

I am finding the post-processing method to improve the randomness of the True Random Number Generator. Especially, TRNG can pass the NIST SP 800-22 after applying the post-processing.

I tried to apply the Enocoro-128_v2 Pseudo-Random Number Generator as a post-processing method for TRNG. TRNG will supply the seed for Enocoro. Then, Enocoro works and generates the ouput. After applying this method, the result can be improved. TRNG can be passed the NIST SP 800-22.

My question: Why Enocoro-128_v2 Pseudo-Random Number Generator can improve the performance of TRNG?

• What's your definition of a "True Random Number Generator"? What makes it "True", as opposed to a regular Hardware Random Number Generator? IME a TRNG is a hypothetical construct, much like a random oracle, which emits perfectly uniformly distributed uncorrelated unpredictable bits, so there wouldn't be any need to process the output. They're a useful construct for proving some theorems, not a real device. Mar 28 at 1:27
• True Random Number Generator means we use the physical noise sources (Ring Oscillator, PLL, Metastable,...) to generate the random number. Mar 28 at 1:35

It can't, even without knowing how "Enocoro-128_v2 Pseudo-Random Number Generator" operates, as the PRNG will have $$H_{out} < H_{in}$$

You seem to have an entropy source that presumably generates Kolmogorov random samples. Those have a non uniform distribution which you will be able to see from the probability mass function/histogram and that it fails SP 800-22. And they may be autocorrelated. That means $$H_{\infty} \ll 1$$ bits/bit. Run NIST's 800 90b ea_iid test to confirm.

Smearing a PRNG over the top simply masks the underlying Kolmogorov entropy with predictable pseudo entropy ($$H_{\infty} =0$$ from a TRNG perspective). Some people have characterised such a construction as a hardware PRNG. However, for any TRNG to be worthy of the name, it must satisfy the most important aspect of TRNG design, namely that entropy generated > length output. More formally: $$H_{out} \ngtr H_{in}$$.

With a bit of PRNG fudging, any entropy source can produce output entropy at almost infinite rates. For instance, the Intel on-chip TRNG (RDRAND) allegedly produces nearly 2 Gb/s. Clearly Rubbish & balderdash. This chip clearly has $$H_{out} \gg H_{in}$$.

So post extraction, a weakly random source seems to emerge with much better randomness, and a bias away from perfection bounded by the Leftover Hash Lemma:-

$$\epsilon = 2^{-(sn-k)/2}$$

where we have $$n$$ = input bits at $$s$$ bits/bit of raw entropy from the source, $$k$$ is the number of output bits from the extractor (and $$). $$\epsilon$$ is the bias away from a perfectly uniform $$k$$ bit length string, i.e. $$H(k) = 1 - \epsilon$$ bits/bit. NIST accepts that $$\epsilon < 2^{-64}$$ for cryptographic applications.

However, $$\epsilon$$ can easily be made much smaller. I aim for $$2^{-128}$$. For the extractor you could use SHA-512 ($$k=512$$) to minimize entropy loss. You can see the $$n/k$$ ratios and relative efficiencies in these charts:-

So in conclusion, you don't need/shouldn't use a PRNG atop your entropy source. If you're making a TRNG, make it a proper TRNG. Speed isn't all that important.

After all, what can you do with all that Kolmogorov stuff?

• The Intel example was following directly the statement that teh entropy should be larger than the size of the output. I've edited the answer so it is clear that Intel does not do this. Note that for Intel, RDRAND has been defined as "With respect to the RNG taxonomy discussed above, the DRNG follows the cascade construction RNG model, using a processor resident entropy source to repeatedly seed a hardware-implemented CSPRNG." So if you want to attack Intel, you'll probably have to attack RDSEED, not RDRAND (which you seem to do in your linked-to answer). Mar 27 at 15:19
• Could you please try and put a little less negative emotion in your posts? Statements such as the now removed "... and I don't care" will trigger negative sentiments, which are not helping the quality of the answer. Similarly, you are indicating that Intel has "rubbisch" RDSEED, while only linking to your own answer. Why not call it "highly questionable"? That led me to an earlier downvote, before I decided that I actually agree with the gist of what you are writing down and performed the edit to make it easier to understand / a bit more formal. Mar 27 at 15:24
• Maybe you could give an example input size for SHA-512 w.r.t. the expected number of bits generated by the entropy device? I presume you are using concatenation of the generated hashes afterwards? Mar 27 at 15:33