5 ms·

We do: https://en.wikipedia.org/wiki/RDRAND https://en.wikipedia.org/wiki/RDRAND However it's difficult to be sure it hasn't been backdoored, so it's not advis

We do: https://en.wikipedia.org/wiki/RDRAND https://en.wikipedia.org/wiki/RDRAND However it's difficult to be sure it hasn't been backdoored, so it's not advisable to use it directly for cryptographic purposes. Worse, as DJB explains, it's hard to mix a potentially backdoored random number generator with other random numbers in a secure fashion: http://blog.cr.yp.to/20140205-entropy.html http://blog.cr.yp.to/20140205-entropy.html

oconnor663 6y ago
That "malicious hardware RNG" scenario has always seemed odd to me. The idea is that it's going to spy on the contents of your entropy pool (or on your entropy sources, or both) and then generate malicious random bits to exactly cancel out what's in your pool, leaving you with all zeros or something like that. My question is, if you have the capability to pull off an attack like that, wouldn't you probably also have the capability to do much worse things? Like just reading and writing arbitrary memory?
- petertodd 6y ago
  There's two issues: 1) Hardware has severe limitations on what you can actually implement, because implementing complex behavior with small numbers of low-level logic gates is really difficult. 2) You really don't want to get caught when the evidence of the attack is baked into the hardware itself. Under those constraints, a very subtle attack on an entropy pool could be both easier to implement, and much harder to notice, than an obvious attack of just flipping some "root access bits" or backdooring the key generation directly. It's quite difficult to prevent those kinds of attacks from being detected by debuggers, under the constraints of a hardware implant. In particular, remember that the mechanism where the backdoored RNG can observe state might be a deliberate leak, implemented by the programmer of the RNG pool, working with the people doing the hardware implant. In that scenario, they want something subtle so it'll pass code audits. If you haven't already, I'd really suggest trying out some FPGA development. Basically, everything is done with fixed-function state machines, and abstractions and complex behaviours are really difficult to implement directly. I'd say FPGA design in comparison to, say, assembly, is similar to the difference in abstraction power between assembly and Python.
Enginerrrd 6y ago
Ah, I get it now. Thanks for the information.

oconnor663 6y ago

That "malicious hardware RNG" scenario has always seemed odd to me. The idea is that it's going to spy on the contents of your entropy pool (or on your entropy sources, or both) and then generate malicious random bits to exactly cancel out what's in your pool, leaving you with all zeros or something like that. My question is, if you have the capability to pull off an attack like that, wouldn't you probably also have the capability to do much worse things? Like just reading and writing arbitrary memory?

petertodd 6y ago
There's two issues: 1) Hardware has severe limitations on what you can actually implement, because implementing complex behavior with small numbers of low-level logic gates is really difficult. 2) You really don't want to get caught when the evidence of the attack is baked into the hardware itself. Under those constraints, a very subtle attack on an entropy pool could be both easier to implement, and much harder to notice, than an obvious attack of just flipping some "root access bits" or backdooring the key generation directly. It's quite difficult to prevent those kinds of attacks from being detected by debuggers, under the constraints of a hardware implant. In particular, remember that the mechanism where the backdoored RNG can observe state might be a deliberate leak, implemented by the programmer of the RNG pool, working with the people doing the hardware implant. In that scenario, they want something subtle so it'll pass code audits. If you haven't already, I'd really suggest trying out some FPGA development. Basically, everything is done with fixed-function state machines, and abstractions and complex behaviours are really difficult to implement directly. I'd say FPGA design in comparison to, say, assembly, is similar to the difference in abstraction power between assembly and Python.

Enginerrrd 6y ago

Ah, I get it now. Thanks for the information.