Infinite Noise true random number generator
tindie.com
tindie.com
"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?
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.
This is why hardware RNG is such a hard sell. Constructs like clockspeed, FLOPS, memory bandwidth, I/O throughput are easy to understand when compared to the more abstract idea of "better randomness".
You don't xor the RNG to itself - why would you do that? That's not safe if the RNG is backdoored. (Never xor dependent streams together!)
Instead you just xor all the random sources you can find together, and use that final value as the random value. Even if you xor a well known value into your random value you have no in any way harmed the randomness of your existing value - it's still random. So the hardware RNG can never make it worse.
And you keep saying 'bps' - bits per second, which makes no sense in this context. The goal is not to increase the throughput of the random stream by using a hardware generator (you might reduce cpu usage, but that's not the goal), the goal is simply better random values.
Corrupted TRNGs don't make things worse, but also not better, and you keep depending on your existing entropy sources, whatever their quality may be.
Therefore providing computers with TRNGs made by Intel etc. would only create a false sense of security.
> would only create a false sense of security.
You are assuming that your only adversary is the chip maker, but this type of RNG (if it were even possible to make it) would still be helpful in the other 99.99% of uses for randomness.
His writeup assumes the attacker knows everything about the way the random stream is generated. But a mass market CPU would not be able to do that.
Even a simple "replace a RNG xor a register with <backdoored RNG>" in the microcode would catch almost everything. And remember - microcode updates happen all the time, and are not open. It's entirely possible that the microcode is updated in response to the type of RNG verification - in other words, with the attacker knowing everything about the way the random stream is generated, as you say.
It seems like you think the random stream is generated mathematically. It's not, it's based on various timing events, mouse movements, keyboard, etc. A mass market CPU would not be able to handle any of that.
You could always get the CPU random number first, then the external randomness - it would have to predict the future to do anything about it.
> the microcode is updated in response to the type of RNG verification
Hu? I don't understand what you mean. What RNG verification? You would have to tune to the microcode to the specific version and settings of the OS getting the random data, including which hardware was attached.
You massively underestimate how hard this would be. Yes, perhaps the NSA could do it for a single well known adversary - maybe - I doubt it, but maybe. But it would certainly be impossible in mass.
Sure it is. To be non-independent it has to know your other entropy streams and cancel them.
Just being backdoored (i.e. I know the pattern) does not make it dependent.
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...
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.
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.