> This USB key RNG also demonstrates what I feel should be considered best-practices for TRNGs. It is low cost, reasonably fast, and has no firmware that can be used to PWN your computer. The USB key can easily be taken apart (with care!) using a toothless dinner knife, so the board can be compared to those on the github site.<p>It's interesting to compare to another well known USB RNG, the Simtec's Entropy Key[1], which apparently is no longer available. The Entropy Key takes the opposite approach both on firmware and on easy of taking it apart.<p>Here's an overview of how Entropy Key worked (more detail on the "technical" tab on their site). They have two separate reverse biased PN junctions generating random streams. These streams are each tested using Maurer's universal statistical test for random bit generators, and their entropy is conservatively estimated. If the test fails or the entropy is too low, it is a fatal error and the device stops sending random data to the host, and reports an error.<p>The two streams are also xor'ed together, and that combined stream is tested with Maurer's test and its entropy is estimated. If this fails, it is fatal. (Combining the streams this way detects if the two generators have become correlated).<p>The two streams go through von Neumann debiasing, and are tested again with Maurer's test, and the entropy is estimated. If the test fails, or the entropy is varying too widely, fatal error.<p>The streams then go into a 256-bit cryptographic hash. When enough bits have gone in so that the input entropy is at least 150% of the number of output bits of the hash, the output is taken.<p>The hash output is mixed into a bit pool. When the pool has taken in at least 50% more entropy than it could possibly hold, a new pool is started. Enough pools are maintained to have 20000 bits of total pool data. The pool blocks are then tested following FIPS 140-2. The 20000 bits are then available for delivery to the host.<p>The protocol for host communication encrypts the data blocks that contain the random bits, using a session key based on a shared secret between the device and the host.<p>The device is filled with epoxy, and opening the case should destroy it.<p>So, are they any security experts who can comment on which is closer to best practice? A minimal device that just delivers fairly raw bits, with all the statistical testing and other processing necessary for good random numbers up to the host, and with no protection against hardware tampering (other than hoping that tampering would mess up the stream in a way the host will notice)? Or a device that does the testing and processing, and delivers ready to use random bits to the host, and that tries to prevent tampering?<p>I would think that even with the simple approach, you should put two theoretically identical generators on the device. That way, if someone does try to influence the device by external means, you have a better chance of detecting it because if it influences both devices the same way you'll get correlations.<p>[1] <a href="http://www.entropykey.co.uk" rel="nofollow">http://www.entropykey.co.uk</a>