
A Brief Rundown Of The Spying Questions Intel’s CEO Won't Answer - danielsiders
http://www.fastcolabs.com/3026860/a-brief-rundown-of-the-spying-questions-intels-ceo-wont-answer
======
tptacek
The article's title is misleading; Intel has answered this question. They deny
collaborating with NSA.

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.

~~~
cperciva
_But RDRAND is a stupid backdoor_

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.)

~~~
pbsd
I've tried to diagnose when the RDRAND failures happen. From my experiments on
Haswell, it only seems to happen when you have > N threads, where N is the
number of physical cores, simultaneously reading continuously from RDRAND. But
when that happens, nearly every read from every thread will fail.

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.

------
bananas
But he did answer them:

[http://www.reddit.com/r/IAmA/comments/1ycs5l/hi_reddit_im_br...](http://www.reddit.com/r/IAmA/comments/1ycs5l/hi_reddit_im_brian_krzanich_ceo_of_intel_ask_me/cfltop4)

The wording is carefully chosen so I'll let people draw their own conclusions
from it.

~~~
jnbiche
"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."

To me, that statement strongly suggests that Intel _is_ participating in
_some_ sort of NSA program. What that is, I have no idea.

~~~
ama729
> To me, that statement strongly suggests that Intel is participating in some
> sort of NSA program.

Well, they certainly do, since the NSA have some public work on cryptography
IIRC.

------
ama729
I'm not knowledgeable in the intricacies of cryptography, so this is something
that bug me, how can the Random Number Generator be backdoored in a way that
would be usable for the NSA without being detectable?

Surely you could graph the numbers that the RNG output and see if it's random
or not, no?

~~~
sweettea
A sequence can be completely deterministic and yet pass all randomness tests.
For instance, if I tell you I randomly chose numbers between 0 and 16,
inclusive, and got 14, 13, 10, 1, 6, 5, 2, 9, in that order, as far as you can
tell it looks random. However, x_{n+1} was generated by taking (3 * x_n + 3) %
16, and hence I can predict the next random number in the sequence trivially.
[This is a bad random number generator for other reasons --- see Wikipedia on
LCGs for more --- but a good demonstration of how random numbers can appear
random but be usable by $attacker.]

~~~
dredmorbius
A sequence of digits take from pi or e would be randomly distributed but
completely deterministic.

~~~
jjgreen
It is not known whether the digits of pi are evenly distributed.

~~~
dredmorbius
NB: what I said was "randomly", not "evenly".

Though I doubt we'll ever get to the end of this one.

------
conformal
a favorite song of mine by kool keith comes to mind: "i don't believe you" (
[https://www.youtube.com/watch?v=Bc5cOohfHhA](https://www.youtube.com/watch?v=Bc5cOohfHhA)
).

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.

------
yuhong
Personally, I asked about early Pentium Ms lacking PAE.

~~~
bananas
That's fairly obvious I think.

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.

------
fiatmoney
Intel NICs are a far more plausible, useful, and hideable location for a
backdoor (or even just an unintentional vulnerability) than RDRAND.

