Re: use of RDRAND in $random_library
Josh Triplett <josh@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: