Live data from Hacker News

Encrypt your Google chats and make the NSA sad

github.com

151–160 of 195 posts

Re: Encrypt your Google chats and make the NSA sad

#151
post #2

As far as I can tell, this is using CBC mode without any authentication: https://raw.github.com/mdp/gibberish-aes/master/dist/gibberi... If that's the case, then this implementation is vulnerable to a variety of attacks.

It's worse that that. It uses a questionable javascript crypt library (written by a former twitter dev, not a cryptographer) and a fixed IV derived from the password which is re-used for each message. This is oh I read the wikipedia article on AES level cryptography deployed against people who would have written the Wikipedia entry if not for that fact that what they know is probably not public. Better idea: Just mak…

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 
This will zero all but the first 32 bits of the AES key, allowing easy brute forcing.

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.

Re: Encrypt your Google chats and make the NSA sad

#153
post #28

This would definitely be the level of security that falls under this statement from Snowden: Q: Is it possible to put security in place to protect against state surveillance? A: "You are not even aware of what is possible. The extent of their capabilities is horrifying. We can plant bugs in machines. Once you go on the network, I can identify your machine. You will never be safe whatever protections you put in place.…

"We can plant bugs in machines" doesn't mean that they can do it remotely. That would actually be a serious serious backdoor and would put all kinds of businesses in mortal danger - banking, credit card, online shopping, etc. Imagine what one rogue NSA employee can do with that kind of backdoor access. So ENCRYPT EVERYTHING, and don't believe this propaganda. If your hardware has a backdoor, you're fucked no matter w…

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

Re: Encrypt your Google chats and make the NSA sad

#154

Earlier quoted context omitted.

At least Adium, Gajim, Kopete and qutIM have built-in OTR support. So, I guess, it's a bit more than nobody.

Yeah I remember using OTR on kopete when I was in college. I had one instance opened on my laptop and the other on my PC. It was pretty cool and easy to set up. What wasn't easy was finding anyone I knew to talk to with beside the few other linux nerds at school.

Because people don't know about it.

Re: Encrypt your Google chats and make the NSA sad

#155
post #105

Earlier quoted context omitted.

Most people aren't going to get themselves into webs of trust - and certificate authorities and webmail servers and the like can be compromised. The only thing you can vest any significant trust in, with NSLs and so on flying around, is what's on your computer. And, if you want to be really sure, what's on a computer with no radio protected by an airgap into which you never insert removable media....

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.

Okay, I'll bite for that - what's your threat scenario here?

Re: Encrypt your Google chats and make the NSA sad

#156
post #100

Earlier quoted context omitted.

What would be hard is also making sure that packet sniffers in the middle wouldn't be able to detect it. Specially with all the varieties of router hardware. Are we going to have a backdoor in all of them that prevents passing on that data?

And you know, given the tens of thousands of people involved in chip design, are we to think that absolutely no one, anywhere, would've leaked that there was some anomalous circuitry in the chip designs which they were told not to worry about it?

It would probably be added pre-fabrication, not right in the chip design.

Re: Encrypt your Google chats and make the NSA sad

#157

Earlier quoted context omitted.

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.

I'm happy with AES and I don't want to write my own crypto. I was asking for a better AES javascript library, because I found a couple of different js AES libraries, but, as you said, I don't know anything about cryptography, and I wanted to know if some are better than others. thanks

You don't need a better AES implementation (well, you probably do, but that's just the start). You need higher level primitives. There a thousand ways to use AES, and most of them are insecure, including your implementation.

Re: Encrypt your Google chats and make the NSA sad

#158
post #132

Earlier quoted context omitted.

Have a good time waiting, sir. In the meanwhile you might be interested in the following fact: 1. Google is removing XMPP as protocol http://www.zdnet.com/google-moves-away-from-the-xmpp-open-me... 2. On the other hand, however, duckduck is giving us some alternatives https://duck.co/topic/duckduckgo-s-new-public-xmpp-jabber-se...

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

And you don't think the EU isn't already doing pretty much the same thing?

Re: Encrypt your Google chats and make the NSA sad

#159
post #83

This would definitely be the level of security that falls under this statement from Snowden: Q: Is it possible to put security in place to protect against state surveillance? A: "You are not even aware of what is possible. The extent of their capabilities is horrifying. We can plant bugs in machines. Once you go on the network, I can identify your machine. You will never be safe whatever protections you put in place.…

Further thinking along this line: most people in the world today are dependent on their phones and internet for information and communication. A lot of people suspected total listening capabilities and now we mostly know that's the case. But what if the NSA had total interference capabilities, as Snowden's quote implies? I suspect it does. I've been finding HN to be a hub for all the facets, ideas, and fallout from t…

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.

Re: Encrypt your Google chats and make the NSA sad

#160
post #156
post #100

Earlier quoted context omitted.

And you know, given the tens of thousands of people involved in chip design, are we to think that absolutely no one, anywhere, would've leaked that there was some anomalous circuitry in the chip designs which they were told not to worry about it?

It would probably be added pre-fabrication, not right in the chip design.

It could also be added in the firmware, either during manufacture, or via zero-day exploits in the firmware. The largest entries in /lib/firmware are all for network cards. Since the NIC has DMA access and can interrupt the CPU, the NIC firmware could be used to attack the OS.

There's still the question of packet sniffing by an intermediate device. The attacker would need to control (the network interfaces of) every device in the chain, use the ability very rarely to avoid detection, or hide data in packet metadata that is later decoded by interception equipment. This third option is probably fairly straightforward on any NIC with TCP checksum offloading.

Post reply on HN