Josh Triplett <j...@joshtriplett.org> writes: > If you don't trust a hardware random number generator, you should not > xor it and another random number source together; after all, if you > believe the numbers coming out of the hardware random source are not > actually random, you might just as easily believe that they're the > precise non-random values needed to xor with another CPU register to > produce non-random values.
I would certainly hope that the mixing algorithm of any decent random number source is better than just xor. And given that, I don't believe the mathematics supports your assertion here. It's considerably harder to backdoor a random number generator to cause a higher-level mixing random number generator that combines multiple sources of entropy to produce predictable random numbers than it is to cause it to spit out predictable random numbers directly. > (Also, if you don't trust a hardware random number generator, you should > ask yourself why you trust any other instruction on your CPU. Because it's way easier to hide a backdoor in a random number generator than it is in other parts of the CPU instruction set. A random number generator does one specific thing, which is unpredictable by the calling code by *definition*, and which has known ways to backdoor via mechanisms that provide the attacker with a trap-door attack. This is far more difficult to do for instructions that are hidden behind layers of unknown future code. Yes, you can add backdoor paths that trigger on certain data patterns, but you have to then engineer ways of introducing those data patterns and the backdoor behavior has to be useful. It's a far trickier problem. By comparison, backdooring the random number generator with a trap-door function gets you a general crypto break of crypto done with that random number generator pretty much directly. > If you don't trust the hardware you run on, you're doomed anyway; This is far too simple of a statement to be accurate. It depends on the type of hardware attack. At best, this statement is true of a targetted, specific attack against one piece of hardware (*your* laptop in particular), which is not what we're talking about here. We're talking about the possibility of embedding a generic backdoor in widely-distributed commodity hardware. The specific attack that people are concerned about here is a long-lived, wide-spread backdoor in a consumer product, which requires very careful design to not be detected. This is far more likely for random number generators because (a) we already know exactly how to backdoor a random number generator in this fashion to allow an attacker with secret knowledge to reproduce the number stream while still passing statistical randomness checks, and (b) the use case for random number generators is very narrow and this sort of backdoor won't be revealed as a bug by other normal use. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tuty313....@windlord.stanford.edu
