Cool product, and great execution.
And interesting thing about entropy is you can never make it worse - you can never reduce entropy by mixing in an independent stream from elsewhere. (A dependent stream is different, it might cancel out something else.)
So you can still use the hardware RNG without hurting anything, unless you think it's so sophisticated it's able to figure out your other sources of entropy and exactly cancel them out.
It seems like an adversary who could swap your rng could install a radio broadcaster between your keyboard and your pc or reboot to a rootkit.
Oppositely, you might paint your rng with sparkles or other unique paint schemes to mitigate that particular switch risk but then you'd still have the other possibilities.
Anyway, I don't think this kind of physical spy versus spy stuff is the main risk a custom rng is intended for.
That said, if you have an adversary that has and is devoting the time and resources necessary to arrange to have someone on the plane with you, with a doctored USB RNG, in a seat where they can get to your laptop when you go to the bathroom and mess with it, you probably should not be traveling alone, and your traveling laptop should be one that never contains important secrets and is never connected to a network that has important secrets.
I made a hash of an hundred files made this way and could not find any collision.
Could this be considered as a TRNG?
https://medium.com/the-physics-arxiv-blog/quantum-random-num...
"There is no algorithm that can generate entropy. Therefore any HRNG depends on input from some hardware device. It is necessary to calibrate the input device. For example, the entropy available from a soundcard depends on the input impedance, gain, bandwidth, and temperature. Calibration is not easy. It requires skill in a number of areas, including physics, electrical engineering, programming, and cryptography. However, just because it is hard is no excuse for skipping this step.
... My favorite proverb of all is the one that says for every proverb, there is an equal and opposite proverb. In this case, we should note that the proverb about not putting all your eggs in one basket is not necessarily a sound engineering principle. The right answer depends on the margin of error and on the per-basket failure rate. It also greatly depends on the chance of correlated, uncorrelated, and anti-correlated basket failures. Sometimes the best way to get your eggs from point A to point B is to put them all in one basket and take really good care of that basket.
... The phrase “random number generator” should be parsed as follows: It is a random generator of numbers. It is not a generator of random numbers."
Intel's DRNG appears controllable through
a software based power droop attack
Anybody have a link to the potential flaw in Intel's RNG?
That seems pretty iffy to me. Humans are really bad at generating randomness, and the entropy from "randomly" typing letters is going to be far less than you think. It's better to go with hard drive and network latency, or the least significant bits of keypress times, which are far noisier than which keys were pressed.
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.
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.
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).
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.
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.
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.
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.
The device is filled with epoxy, and opening the case should destroy it.
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?
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.