[makomk]

Mucking with RDRAND can easily be done in such a way that it's provably impossible to detect any differences in behaviour. It's much harder to guarantee that if you start mucking with buffers in memory, since there are so many clever ways a developer could check their work and catch you out.

[willvarfar]

How's the provably impossible to detect bit work again? Surely it'd fail a Chi Square test on reruns with the same input? The attack can't use external input e.g. clock because the NSA can't correlate generating the random number with seeing it in flight.

[betterunix]

"The attack can't use external input e.g. clock because the NSA can't correlate generating the random number with seeing it in flight."

It could potentially use the number of milliseconds since the last hour, or maybe the state of the branch predictor, or any number of other things that have exploitable biases (with NSA resources, 1/1000000000 is pretty good odds).

[Perseids]

Why should the CPU not have an internal counter that is backed up in flash memory between reboots? 128bit would be enough, with the highest bits set to the processor serial number. Using this counter in AES-CTR mode – i.e. encrypt the counter with the secret key to generate the pseudo random data – the NSA could reconstruct the internal CPU state from a single block (16 bytes) of random data. As many random data is published verbatim, for example as nonces, getting such a block should not be a problem.

[willvarfar]

You are completely right.

https://plus.google.com/117091380454742934025/posts/SDcoemc9... and https://lkml.org/lkml/2013/9/6/205 are interesting explanations too.

[makomk]

Yeah, or if the onboard flash memory is too difficult to implement, they could even just initialise the lower bits of the counter from the real hardware RNG every boot. Either of these options would be statistically indistinguishable from true randomness unless you knew the key.