4 ms·

I've always wondered why TRNG like this one were not included in computers already. I know modern CPU also take advantage of physics phenomena (supposedly), but

by steeve 12y ago

I've always wondered why TRNG like this one were not included in computers already. I know modern CPU also take advantage of physics phenomena (supposedly), but still... Cool product, and great execution.

TheLoneWolfling 12y ago
The problem is that it's pretty much impossible to verify that a supplied RNG is actually a secure RNG and isn't backdoored.
- ars 12y ago
  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.
  - desdiv 12y ago
    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".
    - ars 12y ago
      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.
      - UweSchmidt 12y ago
        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.
        ars 12y ago
        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.
  - TheLoneWolfling 12y ago
    That is true in the case of independent sources. But a backdoored RNG is probably not an independent source!
    - hdevalence 12y ago
      See, for instance, http://blog.cr.yp.to/20140205-entropy.html http://blog.cr.yp.to/20140205-entropy.html for a writeup by djb on a possible way to exploit this in practice.
      - ars 12y ago
        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.
        TheLoneWolfling 12y ago
        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.
        ars 12y ago
        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.
- rtpg 12y ago
  so how does this key help? How can you know this isn't backdoored somehow?
bigiain 12y ago
Some do: http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ http://scruss.com/blog/2013/06/07/well-that-was-unexpected-t...
frozenport 12y ago
Perhaps random number aren't in demand, beyond the resources currently supplied?

by steeve 12y ago

TheLoneWolfling 12y ago

The problem is that it's pretty much impossible to verify that a supplied RNG is actually a secure RNG and isn't backdoored.

ars 12y ago
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.
- desdiv 12y ago
  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".
  - ars 12y ago
    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.
    - UweSchmidt 12y ago
      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.
      - ars 12y ago
        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.
- TheLoneWolfling 12y ago
  That is true in the case of independent sources. But a backdoored RNG is probably not an independent source!
  - hdevalence 12y ago
    See, for instance, http://blog.cr.yp.to/20140205-entropy.html http://blog.cr.yp.to/20140205-entropy.html for a writeup by djb on a possible way to exploit this in practice.
    - ars 12y ago
      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.
      - TheLoneWolfling 12y ago
        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.
        ars 12y ago
        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.
rtpg 12y ago
so how does this key help? How can you know this isn't backdoored somehow?

bigiain 12y ago

Some do: http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ http://scruss.com/blog/2013/06/07/well-that-was-unexpected-t...

frozenport 12y ago

Perhaps random number aren't in demand, beyond the resources currently supplied?