A True Random Number Generator, or TRNG, obtains fresh unpredictable inputs by measuring a physical process. This differs from a generator that only calculates further values from stored state. In practice, the two can work together. But “true” is not a quality guarantee: a physical source can also be poorly designed or faulty.
A circuit can measure small electrical fluctuations and turn them into numbers. What matters is how much of the measurement an attacker cannot predict. Producing a lot of data quickly is not enough. NIST SP 800-90B therefore assesses the particular noise source, its sampling, any processing, and checks that it is working properly. Naming the physical phenomenon does not replace that assessment. [1]
A source might produce zeros more often than ones. Processing called conditioning helps reduce that bias and concentrate available entropy—uncertainty from an attacker’s perspective—into a shorter output. It cannot create missing uncertainty. NIST SP 800-90B therefore ties credited output entropy to the input and the method used. Even a hash, a calculated fingerprint of data, does not prove that the original values were unpredictable: a known input lets someone calculate the same fingerprint again. [1]
If the source keeps returning the same value, the device must not overlook it. NIST SP 800-90B uses the Repetition Count Test to monitor repetition and the Adaptive Proportion Test to monitor unusual frequencies. These checks look for certain faults; they do not automatically detect every attack or defect. Once a persistent failure is detected, the source must not keep supplying output as if operation were normal. [1]
The presence of a TRNG alone does not establish that a wallet is secure. How the particular version uses its data and handles errors matters too. NIST SP 800-90C therefore considers sources together with the generators that follow them. Assessing one component is not the same as assessing the entire wallet. Even an excellent randomness source cannot protect a backup you later disclose. [4]
A long recording from a running device reveals a different part of its behavior than repeatedly stopping and starting it. NIST SP 800-90B therefore also includes restart tests. Assessment must match the particular source and its operating conditions. A result for one sample cannot automatically cover all devices or environments. A firmware change—the program inside the device—may also require reassessment. [1]
Technical documentation mentions the RDRAND and RDSEED instructions. Intel describes them in its guide to the DRNG, a hardware random number generator. RDRAND supplies results from a deterministic generator that calculates further values from internal state. RDSEED supplies conditioned entropy for initialization, meaning the creation of a generator’s starting state. Both paths may begin at a physical source; neither therefore promises direct access to unprocessed noise. [2]
A processor may not have a result ready for every request. Intel therefore requires checking the CF status flag for both RDRAND and RDSEED: 1 means a result is available, 0 means it is not. Merely checking for numeric zero in the destination register, a small storage location in the processor, is insufficient. The program must read the success flag. A processor supporting an instruction does not mean that a particular request succeeded. [2]
On Linux, the hw_random interface allows hardware-source data to be read through /dev/hwrng much like a file. Its documentation explicitly warns that this interface does not itself apply fitness tests to the data. Faulty or tampered-with hardware may therefore return bad data that an application can still read. Successful reading does not prove sufficient entropy. Both the source and the program’s handling of its output need assessment. [3]
For the clearest picture, read this entry together with Cryptographic Entropy, Random Number Generator, CSPRNG, Entropy Mixing. The reverse links also lead from Entropy Mixing.