That's the quote that jumped out at me too. The solution for those who want to stay out of NSA's reach is to use your own hardware, and use open source software (where it's hard to put a backdoor without being discovered) and strong encryption.
Could someone add a backdoor to git that hides backdoors from showing up in git? Could gcc be backdoored to add backdoors to arbitrary software? How likely is it that NSA has a few zero-days lying around they could use to hack into the servers that host git or gcc or any other tool you rely on? What if they had agents among the committers and maintainers of these projects?
Security against a well-armed, well-funded, well-organized, secretive adversary is hard.
This, however, is not a decidable problem. It is possible to construct a program that will fool the worm and thus you can create a compiler that you know you can trust for this test. It will probably be a hard compiler to use, but you will need it at most twice -- once to check for an attack, and if there is an attack once more to bootstrap a clean compiler.
i.e., you actually have to have an example of a compromised compiler, which pretty much solves the problem in the first place.
If you decidedly don't-trust the only compiler on your system, and don't trust outside sources, the only solution is to hand-assemble a new compiler on the system, and hope that at least the hardware is trustworthy. which it isn't, necessarily.
You can't rely on a backdoor looking like this:
if(!strcmp(username, "secretagentman")) { … }Anything in the leaked docs on that particular incident?
Perhaps I lack the wherewithal to identify security vulnerabilities in deployed code, but there's a good chance that there are others who are able to spot said vulns.
I'm talking about vulnerabilities in crypto software no in email clients, browsers or office software (that probably they use too)
Nobody seems to know if the NSA actually has practical attacks against primitives like AES or SHA-2. We do know for sure that they go after higher level implementation flaws. The more complex your encryption scheme is, the more likely it is that you'll introduce a grave flaw. It only takes one.
I'd suggest that our best bet already exists: NaCl[1]. It's by Daniel Fucking Bernstein, so the implementation is as flawless as it gets. Better yet, it doesn't use a single US-approved primitive (not even the NIST curves Schneier was warning against in his Guardian piece).
Funnily, before the leaks Bernstein's use of all his own primitives was seen as a bit wacky and concerning, but now it seems almost sensible.
[1]: http://nacl.cr.yp.to
The reason we don't do that is, of course, CPU cost.
working with chipmakers to insert back doors
So you're going to need to make your own chips, too.
http://www.cl.cam.ac.uk/~sps32/sec_news.html#Backdoor
> Abstract. This paper is a short summary of the first real world detection of a backdoor in a military grade FPGA. [....] The backdoor was found to exist on the silicon itself, it was not present in any firmware loaded onto the chip. [....]