Understanding Intel's Ivy Bridge Random Number Generator (2012) | Hacker News Reader

Understanding Intel's Ivy Bridge Random Number Generator (2012)

electronicdesign.com

60 pointsdoppp9 comments

The main problem that people have with this, is basically there is no way to verify that the design matches the actual implementation. At least there is no way you or I could do it. After the Snowden Revelations, trusting becomes difficult. That is why basically everyone who uses this instruction, mixes it with other data to make sure that even if this generator really was backdoored, the damage is limited

Except with the right (obvious) non linear filter you can easily extract orders of magnitude smaller signals randomly inserted in a white noise

That is the basics of how people in astronomy clean their signal.

http://beauty-of-imagination.blogspot.fr/2012/09/fun-with-si...

It's interesting how the blog post think this is surprising, and how some basic techniques are rediscovered

The average filter is basically correlating the input signal with a (window sized) square wave

It's one of the most basic denoising techniques available (for AWGN)

"The moving average is the most common filter in DSP, mainly because it is the easiest digital filter to understand and use. In spite of its simplicity, the moving average filter is optimal for a common task: reducing random noise while retaining a sharp step response. This makes it the premier filter for time domain encoded signals. However, the moving average is the worst filter for frequency domain encoded signals, with little ability to separate one band of frequencies from another."

It definitely depends on your domain, but moving average/median can be extremely effective. (Or terrible, if mis-applied).

http://www.analog.com/media/en/technical-documentation/dsp-b...

A good pseudorandom generator will pass any such test with flying colours, in fact it's a basic requirement. Bu that is no guarantee that, given a certain length of output, an external attacker couldn't sync up and predict all future outputs.

And I don't believe there is a general way to distinguish such a device from an actual random source without looking inside. For example, they could use AES256 output in counter mode on a low entopy chip ID + high entropy backdoor key. Trivial to bruteforce given a few words of output, but you would essentially need to break AES to detect it.

One problem with that approach is that depending on how little you trust the general area around RDRAND, it doesn't work.

Now, before I continue, I should mention that Intel explained that in their design the back-end of RDRAND is completely separate from other (micro)architectural state (like registers). [However, this restriction does not help if you were to assume that e.g. RDRAND microcode is evil].

Theorem of poisonous entropy: Given an attacker able to observe the state of your CSPRNG, they can embed information in the CSPRNG output with negligible computational cost iff they are able to supply entropy.

Therefore, if you don't trust RDRAND to not spy on you, but still use it as an entropy source, you cannot build a secure CSRPNG.

If you distrust Intel to even separate the CSPRNG from architectural registers, you should probably assume that they've compromised even pure-software CSPRNGs running on their chips as well.

Gosh, the most important image (Fig 1) is broken :(

edit: wait, all of them are :(

http://web.archive.org/web/20130115144812/http://www.electro...

Reply on news.ycombinator.com