That's not entirely true. You can mix the entropy of the hardware RNG with other entropy.
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.
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.
I was not able to parse your sentence in quotes, so I can not reply to it.
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.
Let's say your kernel currently compiles N bits of entropy per second from various sources. If you add a new hardware RNG that produces 1024N bps, you won't be able to simply append the two streams together to get 1025N bps, because that would be extremely unsafe like you pointed out. The best you can do is periodically xor the output of the hardware RNG onto itself ten times so that you get N bps, and you xor that with the original trusted entropy stream. By the end of the day you still only have N bps, it's just that these new N bps have "better randomness".
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.
Any vendor of hardware RNGs can easily and secretly be forced to build in a backdoor (including the one we're discussing here, as you kinda need to trust that these tiny little microchips do what they claim to do). Actually, selling fake TRNGs would be a low cost, high reward excercise for any intelligence agency anyway.
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.
I think you majorly underestimate the "easily" part. You can make a pattern with your RNG, but once mixed it's pretty useless. Making one that can handle that is not in the slightest easy.
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.
Comments
That's not entirely true. You can mix the entropy of the hardware RNG with other entropy.
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.
That is true in the case of independent sources. But a backdoored RNG is probably not an independent source!
See, for instance, http://blog.cr.yp.to/20140205-entropy.html for a writeup by djb on a possible way to exploit this in practice.
You oversell the "in practice" part. That is not in the slightest possible in practice.
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.
It doesn't need to.
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.
I was not able to parse your sentence in quotes, so I can not reply to it.
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.
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.
Let's say your kernel currently compiles N bits of entropy per second from various sources. If you add a new hardware RNG that produces 1024N bps, you won't be able to simply append the two streams together to get 1025N bps, because that would be extremely unsafe like you pointed out. The best you can do is periodically xor the output of the hardware RNG onto itself ten times so that you get N bps, and you xor that with the original trusted entropy stream. By the end of the day you still only have N bps, it's just that these new N bps have "better randomness".
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".
I don't think you have understood this.
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.
Any vendor of hardware RNGs can easily and secretly be forced to build in a backdoor (including the one we're discussing here, as you kinda need to trust that these tiny little microchips do what they claim to do). Actually, selling fake TRNGs would be a low cost, high reward excercise for any intelligence agency anyway.
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.
I think you majorly underestimate the "easily" part. You can make a pattern with your RNG, but once mixed it's pretty useless. Making one that can handle that is not in the slightest easy.
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.