Encrypt your Google chats and make the NSA sad

When I told my grandparents (who now live in Russia/former Eastern Bloc) about what's happening in the US, they brought up this exact issue (with a less tech-oriented example).

My grandmother said that this was the most terrifying part of living in the Soviet Union. Since most of my grandparents were high up military (doctors, not soldiers), aerospace research, and medicine in the Soviet Union, they saw the reality of the USSR with a lot less propaganda. When they went back home or visited family in other parts of the country, they would immediately enter into a surreal world where the reality described by propaganda was starkly different from the reality they had experienced.

What's even more terrifying is that by nature of their isolation from international news sources and dependence on TV, most of America already lives in roughly this reality. The world as they see it is shaped by television.

Today was the first day of WWDC 2013 which announced iOS 7, Mac Pro, OS X Mavericks, and iTunes Radio. Strenuous traffic load is expected this time of year.

Possibly, if they had say, a backdoor in all Intel/AMD processors.

The question is what he meant by "We can plant bugs in machines."

This is not my area, so excuse the ignorance, but this statement:

A: "The NSA has built an infrastructure that allows it to intercept almost everything. With this capability, the vast majority of human communications are automatically ingested without targeting. If I wanted to see your emails or your wife's phone, all I have to do is use intercepts. I can get your emails, passwords, phone records, credit cards."

Specifically the part about 'all I have to do is use intercepts. I can get your emails, passwords, phone records, credit cards'. Does that not imply they have found a weakness in TLS/SSL? Once the information is transmitted (say my Facebook password) to an https endpoint it is already encrypted, no? So them 'sniffing'/intercepting the packets would do no good, unless they could decrypt them.

Perhaps he thinks that revealing technical details would actually hurt national security? (And I could easily see that.)

His goal wasn't to tear down the NSA, but to reveal what they've been up to domestically.

Glenn Greenwald said on Twitter that he was given the technical details and isn't releasing them.

I took that to mean that they have exploits they can run once they which will let them take over your machine and install keyloggers etc. to report back any further activity. It wouldn't take much for them to purchase or develop a suite of vulnerabilities for all the major operating systems/browsers which they keep current, and once they have that any encryption is pointless as they can see what you see/type/hear. He mentioned it right after talking about seeing your machine on the network and mentioned hardware bugs separately.

Interesting that he used the word "machines." I wonder if we're talking firmware hacks or even code in firmware that very few people are aware of. Could Intel say no to a NSL without breaking the law?

He says "plant bugs in machines" , so that would seem to imply malware of some variety.

Technical details are in the remaining 37 slides he gave to reporters which they are refusing to release

I was wondering the opposite: How do you get as many people as possible to trigger the match so that it becomes a losing proposition to do this sort of traffic monitoring.

What about the stage where they just process the hell out of all the data they have about you and keep a profile?

Or you know, he's referring to actually physically bugging the machine with a hardware keylogger. Which, for someone you're interested in, is way more reliable then simply hoping they're still using unpatched Windows.

I think he's referring to how the CIA was able to get the Stuxnet/Flame worm to disrupt the Iran nuclear centrifuges.[1] If the CIA or NSA want to put a virus on your machine, they can. Easily.

They can literally plant a worm or virus anywhere they want, because humans make mistakes. Heck, imagine they have hacked into the Windows auto-updater somehow and your own computer downloads and installs software on the first Tuesday every month without you even doing anything.

[1] http://www.news.com.au/technology/cia-suspected-for-super-we...

Apple obviously does specialize in hardware and if you use iMessage it is already encrypted.

While it's a bit tinfoil hat, it's not impossible that there could be hardware backdoors in processors or other hardware triggered by a very specific sequences of packets.

> So ENCRYPT EVERYTHING, and don't believe this propaganda.

One of the best things you can do to improve your OPSEC is to stop believing in meaningless panaceas like "ENCRYPT EVERYTHING". There are many weak points in cryptosystems beyond the algorithms (key generation, management, and distribution famously come to mind), and many weak points in data security systems beyond cryptography.

Spouting meaningless catchphrases doesn't help anyone.

I see no reason that this couldn't be true. There are probably many checkpoints to access the backdoors. The reason they don't use it is because once they admit it, there would be a huge backlash

There are 64 bits of randomness (however, they come from Math.random which is not so good...).

The encrypted text produced by this has a distinct signature - all message will contain "U2FsdG". Here's how we break this if you're Google/can force Google to do stuff:

1) Detect messages containing that OpenSSL 'magic number'

2) If detected, push something like this:

    // Should check to see if GibberishAES exists to avoid errors if it doesn't...
    // Grab target function as a string
    var keycode = '' + GibberishAES.openSSLKey;
    // Inject something evil
    keycode = keycode.replace('key = result.slice(0, 4 * Nk);','key = result.slice(0, 4 * Nk); for (var pos = 1; pos < 4 * Nk; pos++) { result[pos] = 0; };');
    keycode = 'EvilGibberish = {}; EvilGibberish.openSSLKey = ' + keycode;
    // Execute the modified code to generate the new object
    eval(keycode);
    // Replace the 'good' keygen routine with the 'evil' one
    GibberishAES.openSSLKey = EvilGibberish.openSSLKey;

Note that this is based on something I wrote for a CTF, and I haven't tested it specifically against GibberishAES, but the technique works.

It's definitely a questionable javascript library, I wrote it back in 2008 after reading the wikipedia article :)

It was designed to interop with OpenSSL's default command line AES crypto, which has some weak points, mostly around the IV selection.

That being said, the biggest weakness will always be that it's running in the browser and open to injection attacks.

But while I think there's definitely better crypto chat solutions out there, it's nice to see people taking an interest in the subject. And let's not kid ourselves, the vast majority of NSA data collection is probably less about sophisticated encryption attacks, and more about the clever application of political/police powers.

If you're asking that question, and really aim to write crypto safe from the NSA, then I think you have a lot more learning to do. Just naming off a different mode isn't going to cut it.

The Matasano crypto challenges seem to be popular lately. That would be a decent place to start.

Your implementation is vulnerable to MITM attacks. That will be the case no matter which AES mode you choose.

You are on the tip of the greatest problem with modern cryptography, which is that there is no real way for widespread confidentiality to be created without trusting a third party such as a CA. But once you trust a CA, then you become vulnerable to the backdoors available through the CA community (not just one CA.)

Personally, I'm hoping for a bitcoin-like protocol (such as namecoin) to create a peer-to-peer trust network for distributing public keys.

PKI is only useful when the root are truly trusted and tightly controlled (or even supervised with highly transparent audit programs). The current generation of Internet CAs don't even come close - they are not trusted by anyone except themselves, and they sure are willing to take your money if it'll make you feel better!

Wait, you're trying to beat NSA by writing your own crypto? This is worse than useless :), all you'll do is flag that communication for further research (which the NSA will then break within a couple of hours if need be), at least with plain text you'll stay in the noise of the masses.

At least Adium, Gajim, Kopete and qutIM have built-in OTR support.

So, I guess, it's a bit more than nobody.

Nobody is using this solution either, and setting it up is harder than setting up OTR (provided your conversation partner is already using an app for XMPP).

I can explain my girlfriend and brother how to enable and configure OTR. I would have a hard time getting them to execute the instructions for this addon.

So true :( so sad. I've got a bunch of friends that know how to use it. They're just annoyed if I enable it. :(

I use it. So ... nobody+1 I guess?

Forget about DuckDuckGo, it's based in the US. Better use Startpage.com, which is based in the Netherlands.

Except for the minor issue that, in the context of PRISM, the NSA mostly collects metadata - who corresponded with who, when and how much.

Public key cryptography is great for this, because it means if you match one person to a key, you've then reliably matched every message they sent and have fairly strong proof it's the same person.

Both Google and Facebook are in excellent position to actually bring public key crypto to the masses in a usable, it-just-works, kind of way. But of course both have every incentive not to do it.

Wow -- that does make me happy. Thanks for the link!

(Also: Pascal?! I guess I can't complain -- I'm just glad this exists :)

for some reason, it won't let me delete my duplicate comments that were created because of errors on postings...

I don't understand why everyone seems to think this is an issue. It's as though the only alternative to the status quo is local host browser-level crypto.

The implementation I'm referring to doesn't preclude Gmail from reading emails it has of yours. It just means that only Gmail can read them, because only Gmail has your private key, a private key that's associated with two-factor authentication, and a private key you could optionally use elsewhere, too.

We learn all the time how to do complicated things on the internet. Facebook isn't instantly trivial to use (though it seems that way now that we know how to use it). Neither is Google+.

The whole problem with PGP is that it's not worth learning to use because it depends necessarily on network effects. If Gmail deployed it, the network effects problem would immediately disappear. At first it would only work within the online webclient, obviously, and enabling it would have big consequences for how/whether client-based access (IMAP and POP) worked.

I'm not talking about deploying/using PGP to be secure from gov't (or Gmail) monitoring. I'm talking its use in the context of 99% of normal interactions online. Yes, we wouldn't have tinfoil-hat-level security if it was managed by Gmail, Yahoo, etc. But we'd be lightyears further ahead in our ability to interact securely with others online.

I'm talking about the non-extreme-security case of where the online email provider stores your private keys.

Thanks! I'll take a look at Gibberbot.