A Brief Rundown Of The Spying Questions Intel’s CEO Won't Answer
fastcolabs.com
fastcolabs.com
To that, add that there's no evidence anywhere of any such collusion, and that Intel retained Cryptography Research to assess their CSPRNG design.
By pluralizing the word "question", the article injects further misinformation. There's one question people are asking about Intel: "why should we trust the RDRAND instruction?". The question is asked not because there's any evidence that RDRAND is compromised, but because CSPRNGs are a uniquely powerful point in a cryptosystem to insert a backdoor. Backdooring the AES instructions is harder; AES is deterministic, so there's not much you can do with an "evil" AES. Not so with an RNG.
But RDRAND is a stupid backdoor. On every mainstream OS, including the two mainstream mobile OSs, RDRAND is (at best) one of several sources of entropy. In the Linux kernel CSPRNG, in FreeBSD's Yarrow, and in WinAPI's CryptGenRandom, controlling one entropy input (or even all but one of them) doesn't make the CSPRNG's output predictable. So even if it is backdoored --- which would be silly --- that backdoor probably doesn't impact you in any meaningful way.
Cryptographers are wary of RDRAND. It's a closed, proprietary design. Cryptographers would rather you use urandom to get your randomness, and if the OS wants to use RDRAND as one of its entropy sources, whatever. Cryptographers would say this whether it was Intel's hardware RNG, Apple's, Samsung's, or Broadcom's.
RDRAND is a very good backdoor for code written by stupid people. There's a lot of application code which detects the presence of RDRAND and uses it directly instead of asking the OS for entropy.
(FWIW, I doubt RDRAND is backdoored in the traditional sense. I'm absolutely certain, however, that the NSA will take full advantage of the documented not-enough-entropy failure mode which returns all zeroes -- which most RDRAND-using software does not correctly handle.)
This means a user process could easily deplete RDRAND's contribution to the kernel's entropy pool. So encouraging all kinds of application code to use RDRAND is really bad advice. It should at least be a privileged instruction.
That's not misleading. That's simple lying.
Actually DJB has a pretty interesting post about how RDRAND and microcoded instructions could work together to control the OS's RNG output, even if several sources are mixed in, by monitoring the entropy pool and brute forcing each bit: <http://blog.cr.yp.to/20140205-entropy.html>
It's a great post. It just isn't as damning as you might think it is.
http://www.reddit.com/r/IAmA/comments/1ycs5l/hi_reddit_im_br...
The wording is carefully chosen so I'll let people draw their own conclusions from it.
To me, that statement strongly suggests that Intel is participating in some sort of NSA program. What that is, I have no idea.
Well, they certainly do, since the NSA have some public work on cryptography IIRC.
In other words, "we provide methods for authorized access to our products" - and we'll let you figure out who is "authorized".
A strong denial: "Absolutely not"
What he wrote (in part):
First, let me be clear that Intel doesn’t participate in the NSA programs
described in recent news reports. Intel does not participate in anyone’s
efforts to decrease security in technology. We don’t provide methods for
unauthorized access to our products….we don’t create back doors.
No matter what he had said and regardless of how true or false it had been, people would be reading in lies. He's too detailed, he's too vague, he's too forceful, too weak, too formal, too informal — once somebody is convinced you're a liar, there is very little you can say to change their mind.
...hopefully they do a better job at keeping their hardware backdoors (if they exist) off the "market" than they do at press releases. Nobody needs this for their dirty deeds anyway considering the current state of software security, and even a state agency would be stupid to use such capability even if they had it, for obvious reasons.
Surely you could graph the numbers that the RNG output and see if it's random or not, no?
Though I doubt we'll ever get to the end of this one.
Take this example: the output of a cryptographically secure pseudo random number generator (CSPRNG) cannot be determined without knowing it's seed(s) (the initial seed and, optionally, additional seeds if/when re-seeding is done).
Any CSPRNG must pass the "next bit" test or it is not a CSPRNG: the probability of the next bit being 1 is 0.5 (the probability of it being 0 is 0.5 too of course).
So, no, you cannot graph the output of a CSPRNG and see if it's random or not. Because by their very definition outputs of CSPRNG look random.
Yet CSPRNGs are fully deterministic.
Now that is another topic but... The NSA may have an history of also backdooring CSPRNG (Dual_EC_DRBG comes to mind) ^ ^
Actually, according to numerous people I respect on this (Ted T'so comes to mind): no.
It's apparently possible to compromise an RNG in such a way that its output appears to be random -- unless you're aware of the secret.
the world's largest cpu manufacturer, which also happens to be based in the US, _not_ having NSA-mandated backdoors is entirely out-of-the-question. even if the cpus are not backdoored, you can bet all the NIC firmware "happen" to have a remote update path enabled, despite it not having a legitimate application in non-development environments.
intel is tre-owned and always has been.
I'd expect that as Pentium M's were mobile class CPUs, they weren't expected to handle significant quantities of RAM and therefore didn't need PAE. I can't think of a single Pentium M machine I had that ever saw more than 2GB of RAM.