Hacker News Reader

Comment by untog | Hacker News Reader

Because strong encryption can be so effective, classified N.S.A. documents make clear, the agency’s success depends on working with Internet companies — by getting their voluntary collaboration, forcing their cooperation with court orders or surreptitiously stealing their encryption keys or altering their software or hardware.

That's the money quote there- the NSA hasn't cracked encryption. They've just put back doors in.

And we can't even be that angry at the (e.g.) Microsoft execs that authorise the back doors- they potentially face jail time if they resist NSA requests. All the while presumably not able to talk about the requests publicly.

EDIT: and the really fun part - did you know the former head of the NSA serves on the board of directors for Motorola Solutions? http://en.wikipedia.org/wiki/Michael_Hayden_(general)

View on HN

I'm guessing this is what tripped up Lavabit. Mr. Levison probably didn't have the back doors and balked at being complicit once he came onto the NSA's radar.

From the article: "Intelligence officials asked The Times and ProPublica not to publish this article, saying that it might prompt foreign targets to switch to new forms of encryption or communications that would be harder to collect or read."

Also: “Properly implemented strong crypto systems are one of the few things that you can rely on,” - Snowden

I would assume that because Snowden used Lavabit & they shut down that the NSA took issue with how secure Lavabit actually was.

Plus (form the Guardian article) there are covert agents in all the companies, presumably lifting all the certs, which may well be unauthorised, but you can't prosecute.

Do you know who your covert agents are?

Why couldn't you prosecute, if you found out? I assume theft is still theft, even if done by a government employee.

Prosecuting would require contacting an authority that would be willing to take the case, and would also require going public with the fact that one of your "trusted" employees had invalidated your security systems, potentially opening you up to untold amounts of liability from customers who may believe their security has been compromised.

Go ahead, call the cops and media. I hope you have a ton of money on hand and some jewelry stashed away in various locations before you do so.

Perhaps they could arrest you with the old "interfering with a government agent in the performance of his duties" bit.

Good luck with that. You would need the government to prosecute and the government makes it illegal to talk about what you want to prosecute.

Why couldn't who prosecute? That's a function of the government; a prosecutor is not obliged to engage in a case (formally, get an indictment out of a grand jury) whenever they believe a crime to have been committed.

Undercover agents at all levels of law enforcement commit apparently criminal acts every day, with no fear of prosecution. There's no reason for this to be any different.

> That's the money quote there- the NSA hasn't cracked encryption. They've just put back doors in.

It's not like they've just gotten secret keys. They've specifically gotten chip manufacturers to add backdoors to hardware, as well as significantly influenced actual cryptography standards themselves:

> "The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.”

> “Eventually, N.S.A. became the sole editor,” the memo says.

I don't understand that part of the article, what algorithm standard was it? AES?

Presumably that's DRBGs[1]? Does anyone actually use them in that form?

[1] http://en.wikipedia.org/wiki/Dual_EC_DRBG

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.

Remember when Microsoft would trash Linux because it was open source and "not secure." Well, this settles it. Using your own hardware and open source software helps but someone determined will still get in...

Even "your own hardware" is going to be pretty damn hard:

working with chipmakers to insert back doors

So you're going to need to make your own chips, too.

http://opencores.org/or1k/Main_Page

The following isn't directly applicable to your suggestion, but it's a reminder that an FPGA, just like a CPU, may not be doing exactly and only what you told it to do:

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. [....]

RMS doesn't seem such an extremist any more.

I don't agree with RMS on much, but this just goes to show that calling people "extremist" is a logical fallacy. There is only correct and incorrect, and the margin by which something deviates from a commonly accepted norm is irrelevant to judging that.

Refusing to rely on the RNG in Intel processors doesn't seem particularly unreasonable in the light of this revelation does it?

That's a false sense of security. You can inspect every line of code in SSL but unless you are a world-class cryptographer yourself, how will you spot a backdoor in the algorithm?

It's a bit harder to sneak in junk in open source projects. You can see the checkins. However, you are right, if the flaw is in the algorithm itself, it's hopeless.

Is it harder to sneak in junk in open source projects? I'm reminded of Ken Thompson's Turing Award lecture, "Reflections on Trusting Trust". http://cm.bell-labs.com/who/ken/trust.html

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.

There are countermeasures concerning the Trusting Trust attack: http://www.schneier.com/blog/archives/2006/01/countering_tru..., though I'm not sure if anyone has ever seriously attempted to deploy them.

I have given some thought to this kind of thing, and one thing I realized is that the limits of the trusting trust attack can be exploited as well. Let's support you only have one compiler. Now, it is going to try to insert the worm into any compiler it compiles, right? The problem is that it must be able to detect that it is actually compiling a compiler.

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.

But in order to create a disguised compiler, you need to know what method a compromised system uses to decide whether something is a 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.

Could you spot a "trusting-trust"-style backdoor in an FPGA you were offloading crypto to? How would you even start?

http://underhanded.xcott.com/ <-- a contest all about sneaking bad behavior into code without being noticed

You can't rely on a backdoor looking like this:

    if(!strcmp(username, "secretagentman")) { … }

The Debian OpenSSL snafu showed that even rather blatant changes get missed.

Anything in the leaked docs on that particular incident?

The OpenSSL snafu showed us all that _code commenting_ is a really good idea.

The strength of open source lies in the number of eyes with access to the code.

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.

Actually, we don't know if there's a good chance or not. All the best cryptographers in the world, who aren't already working for intelligence agencies, are reliant on government funding (i.e. they're in academia). The fact that these have gone undiscovered so long suggests that finding them will not be trivial.

ability to spot algorithmic vulnerabilities on that level? and doing it for free? the chances are nill

Not completly for free if you use that software, and if you are an expert crytpo guy, it is probable that you use that software.

I'm talking about vulnerabilities in crypto software no in email clients, browsers or office software (that probably they use too)

Can we combine multiple algorithms such that having any one of them be secure is safe? For example, instead of encrypting with just RSA, do one pass with RSA and then another pass with ECC. Instead of just using AES, do one pass with AES, another pass with Twofish, and a third pass with RC4. Does that actually help?

Yes, though there are some subtleties, it's fairly straightforward overall.

The reason we don't do that is, of course, CPU cost.

You can do this but it will probably make it less secure, not more.

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

DJB has always been laughed off as an eccentric paranoiac, and yet as the years go by he almost always ends up being proven right. It's been kind of a funny pattern over the past few decades.

Your statement reveals a real lack of understanding of opensource. Hint; it's open to all, all includes world-class cryptographers. Each contributes their ability for the greater good of all. WCC may not spend their time coding or packaging or whatever. Others will.

No, I'm afraid it is you who are mistaken... About a great many things.

Now, witness the power of my fully operational Utah data center.

Isn't this the fact that NSA has access to the internet companies private key for the SSL certificate? There by giving them the tools to decrypt the initial TLS handshake and then from there you can get the symmetric key and decrypt the rest? Or is there more to it, reading the article I didn't see any hard proof of this.

Reply on news.ycombinator.com