Re: use of RDRAND in $random_library
On Fri, Jun 13, 2014 at 10:09:02AM +0200, Martijn van Oosterhout wrote:
> > Excuse me if I'm blunt here, but I understand that, on the point of
> > using entropy to seed a PRNG, if you have several shitty entropy
> > sources and one _really_ good one, and you xor them all together, the
> > resulting output is as random as the best of them. If your hardware
> > entropy source is faulted and produces just an endless stream of
> > '001001001001001001', xoring it with a valid Golomb sequence will give
> > you something even more random than a Golomb sequence.
> >
> The proof that XORing streams can't reduce the entropy relies on the
> sources being independant. I think the issue here is we don't know if
> RDRAND is independent or not. That said, doing a SHA256 over the output
> should be sufficient (assuming the CPU doesn't see you're doing a hash and
> short circuits it).
Basically, the question is how blatently do you think the NSA could
bugger the CPU. If you believe they can completely bugger the CPU, so
they can detect that you are implementing some explicit crypto
instruction, and change its behaviour, or they can peek ahead in the
instruction pipeline, notice an XOR, determine that one of its inputs
is an RDRAND instruction, and the other inputs come from a read of
/dev/urandom, and then modify the behaviour of the XOR, all in such a
way that the hundreds or thousands of Intel employees that need to
improve, test, debug, etc. the CPU instruction execution engine
wouldn't notice, then you might as well give up now and start
implementing your own CPU from transitors, capictors, resistors, and
wires.
While I am willing to believe they might be able to secretly subvert
or bribe Intel to subvert the RDRAND engine, in some way which no
other or very few other employees at Intel would detect, to believe
they could then do so with the entire CPU is MUCH harder to believe.
There are probably much easier things to do, such as subverting
someone in Red Hat's release engineering department, for example. A
buggered kernel is easier to accomplish, and much harder to detect.
This is one of the reasons why implementing reproducible binary builds
is a realy good idea from a security perspective. This allows you to
spot check that various binaries correspond to the sources that they
claim to be form.
Cheers,
- Ted
Reply to: