Infinite Noise – Simple, Open-Source TRNG
It&#x27;s clear that a lot of thought went into this write-up, but this is not a design that I would use or recommend.<p>(Because you probably don&#x27;t anything about me: I have background in both circuit design and applied crypto, and I have published research on hardware random number generators. I&#x27;m not saying this to bully you into believing me, but rather to give you some motivation to think critically.)<p>The main problem is that the noise sources are <i>implicit</i>: the designer has no control over the spectrum or the relative magnitude of the various noise sources, and there&#x27;s <i>no</i> attempt at rejecting power supply ripple or RF disturbances. (The claim that &quot;it naturally defends against influence from outside signals&quot; is not substantiated, and as I argue below, there is a strong possibility that it is false.)<p>It&#x27;s also worrisome that the author doesn&#x27;t bother to distinguish between &quot;noise&quot; in the technical sense and &quot;noise&quot; in the some-arbitrary-signal sense (e.g., power supply ripple). Only the former has useful statistical properties. The latter is useless at best, and an attack vector at worst.<p>As an concrete example of what worries me: this is a discrete time, positive feedback loop. We are presented with evidence that it has a mode of operation in which its output looks random. Critically, this does <i>not</i> eliminate the possibility that it has another mode that&#x27;s essentially a limit cycle. My intuition tells me there&#x27;s a very good possibility that if the output of the circuit has a heavy enough capacitive load, and the circuit&#x27;s power supply is sufficiently high impedance, the whole thing would lock up into a steady-state oscillation. This is related to the analog design adage: oscillators don&#x27;t, everything else does :)<p>So what&#x27;s the &quot;right&quot; approach (at least, in my opinion)? First, simplicity: fewer moving parts means there&#x27;s less that can go wrong. Second, pick an explicit noise source; the best choice is a diode in avalanche breakdown (this is sometimes conflated with Zener breakdown; they&#x27;re different phenomena, and avalanche is louder). Avalanche generates enough noise that it requires very little amplification, and unlike thermal noise, avalanche is quite insensitive to temperature. Third, make it insensitive to external influences by design: shield it from RF, take special care to ensure power supply insensitivity, etc. Fourth, run wellness tests whenever you sample from the RNG. Intel&#x27;s procedures are a good example [1].<p>Finally, a lot of other comments in this thread have covered this, but under standard cryptographic assumptions there is no reason to run this RNG continuously. Sample a few thousand bits, hash them into a key, and use AES-256 as your PRNG. For a really nice take on randomness mythbusting, see &quot;Recommendations for randomness in the operating system&quot; by Corrigan-Gibbs and Jana [2].<p>[1] <a href="http:&#x2F;&#x2F;www.rambus.com&#x2F;wp-content&#x2F;uploads&#x2F;2015&#x2F;08&#x2F;Intel_TRNG_Report_20120312.pdf" rel="nofollow">http:&#x2F;&#x2F;www.rambus.com&#x2F;wp-content&#x2F;uploads&#x2F;2015&#x2F;08&#x2F;Intel_TRNG_...</a><p>[2] <a href="https:&#x2F;&#x2F;www.henrycg.com&#x2F;pubs&#x2F;hotos15recommendations&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.henrycg.com&#x2F;pubs&#x2F;hotos15recommendations&#x2F;</a>