Automatically encrypt your Gmail account | Hacker News Reader

Automatically encrypt your Gmail account

github.com

90 pointsetherael55 comments

This has good intentions but misses the main point of encryption : no third entity should ever have a copy of the unencrypted message at any given time.

Once your emails get into google servers, the NSA has made a copy of them. NSA copies your emails before you even read them.

You are protecting yourself from someone who has access to your gmail account, not from someone who has a BACKUP of your gmail account.

True, it doesn't protect from every threat model in existence, I've been considering setting up some kind of third party reflector model, but the problem there is that the termination point for the plaintext recipients still requires trust at some level.

I recognise this isn't perfect, but the very fact that in various stories a fuss has been raised about data retention times indicates it might not be completely useless to close the window of vulnerability, another comment in this thread mentions monitoring the incoming messages via IMAP IDLE also which is another idea, but once again there is a non zero window of plaintext messages on the server.

And if nothing else, the thousands of spam messages this will armor with strong encryption will give the fascists something to waste their time on.

> Once your emails get into google servers, the NSA has made a copy of them. NSA copies your emails before you even read them.

I haven't followed the NSA Prism story as closely as maybe I should have, but I'm curious: is this TRUE? Like, is it indisputable fact that the NSA has all your email, or, is it more like, we can't be sure what they do and don't have access to, therefore, it's better to assume the worst?

Of course it isn't true

Because Google is well known for deleting data rather than storing and mining it?

Not sure how that's relevant to "Once your emails get into google servers, the NSA has made a copy of them. NSA copies your emails before you even read them"?

Also, please explain how you would implement a webmail service without storing emails.

It's relevant to the idea that if an email enters Google, it's probably accessable to the NSA, even if you delete it. I was directly responding to:

"is it indisputable fact that the NSA has all your email, or, is it more like, we can't be sure what they do and don't have access to"

They don't need to have second hand copies of the mail when they can just tell Google to give them access.

"implement a webmail service without storing emails." is not relevant to anything I said.

It's not just the servers. In fact, PRISM was one of 5 programs disclosed: http://en.wikipedia.org/wiki/File:Upstream_slide_of_the_PRIS...

FAIRVIEW, BLARNEY, and two whose names were redacted exist in addition to PRISM. They are tapping the pipes and grabbing stuff off of the server.

They can pretty much have whatever they want.

themckman's question is a valid one though. So far, almost everything we know about the NSA's surveillance capabilities seem to come from those leaked slides, and frankly, I don't think a couple of slides are going to be technically accurate. The truth is, we simply do not know the real extent of the NSA's reach.

>I haven't followed the NSA Prism story as closely as maybe I should have, but I'm curious: is this TRUE?

it is the "least untruthful statement".

> or, is it more like, we can't be sure what they do and don't have access to, therefore, it's better to assume the worst?

it is just hard to imagine how they don't have access to something. They obviously capable of accessing everything they want. Thus if they don't access something, it would mean they don't want to. Ed absurdum.

Interesting piece of history btw:

http://en.wikipedia.org/wiki/Martin_Hellman#Computer_privacy...

"Hellman has been a long-time contributor to the computer privacy debate. He and Diffie were the most prominent critics of the short key size of the Data Encryption Standard in 1975. An audio recording survives of their review of DES at Stanford in 1976 with Dennis Branstad of NBS and representatives of the National Security Agency.[12] Their concern was well-founded: subsequent history has shown not only that NSA actively intervened with IBM and NBS to shorten the key size ..."

Your first sentence, precisely.

And really, it doesn't matter whether the NSA has explicit connections into Gmail, your email is backed up periodically by Google already, so plaintext is available to interested parties for quite a while even if you were to empty your trash.

But even before that, many SMTP servers transmit emails in the clear, so it wouldn't matter if the NSA had their hooks into Google if they've got their hooks into the backbones that Google peers with.

Oh, and you lose all read state, all information about when an email was sent, any labels, stars, any reference headers for threading, ...

Seemingly the only threat that this addresses is "someone may hack into my email account and I don't want them to be able to read my email". There are several other methods for solving that particular issue without destroying email metadata and the usefulness of email itself.

> no third entity should ever have a copy of the unencrypted message at any given time.

The first company that offers serious client-side encryption (with steganography + noise thrown in for good measure) is going to make a bundle.

Hint, hint.

The issue here is that you then have to do everything client side. Search,spam/malware filtering etc. So you need a copy of all of the mail on the client. Basically you go back to the days of POP3 or having your gmail account taking 10 minutes to log you in while it downloads everything to local storage.

Couldn't browsers be juiced up to support client side encryption via local private key of a text area before form submission? That coupled with automatic public key decryption would enable gmail, for instance, to actually be secure(-ish-at-least-more-so). I think. Yes?

The general facility of client side private key encryption before form submission of both text fields, areas, and files seems like it would be very useful. Not sure why that's not planned for, say, html5. Odds are I'm sprinkling my own ignorance all over this :)

http://webpg.org/

If this sort of functionality was standardised, simplified and baked in to the major browsers, we'd be able to build all sorts of wonderful software on top of it.

You lose backend search this way. It's a critical feature.

Seems like if you really cared for the contents of a textarea, for instance, you could tokenize the text client side and encrypt each token with the client side private key then you could similarly encrypt the search tokens client side and search serverside not knowing what you were searching for.

However, I take your point. Lots of work, not quite the same. It still seems like the facility should be baked in though so that application's could make the proper tradeoffs.

Seems super vulnerable to frequency analysis though. However, if this is a path you might want to go down, you might want to look at CryptDB, a research project that looks at keeping a server side encrypted database and allows for queries in a principled way: http://css.csail.mit.edu/cryptdb/

Products like CipherCloud reportedly work like you suggest. Unfortunately it's not very secure.

If you split the text into words, discard case and encrypt each word, the NSA can just e-mail you a dictionary file, match the line numbers in the dictionary file ciphertext to line numbers in the dictionary file plaintext, and they've got your secret decoder ring (at least for every word in the dictionary file).

This is where we really need fully homomorphic encryption!

Something like text search should only need partially-homomorphic encryption. For example: encrypt each byte with the same key. Then to search, encrypt the bytes of your search term and send them to the backend. It should be able to find them without knowing what your search term was. There are issues with this exact scheme of course but you get the idea!

There is some research in this area, e.g. http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf

Mailvelope is another client-side browser extension that uses OpenPGP.js to encrypt email that works with gmail, outlook.com, Y! mail:

http://www.mailvelope.com/

Why does it use SMTP to resend the email to yourself instead of just using IMAP to replace the email?

Because I haven't yet messed around with parsing just the message body out for encryption to then do an imaplib append with it.

That said, I think this is worth doing, so it's currently in progress. I just don't have a ton of time at the moment, pull requests eagerly accepted though. :)

What about just modifying GMVault to do this?

I had a brief look at the GMVault source to see if there were any obvious msg constructing bits, but nothing is jumping out at me, do you happen to know where the message construction is done here?

No, I don't know the code, sorry, it just seemed like a good place to start for the IMAP bit.

Thanks to Mannkind, I figured it out and it's in now in case you were specifically after this.

This. I gave up on Rss2Email and rolled my own version using IMAP instead of SMTP. Deliverability from iffy to 100%. Furthermore, you can pre-select the folder (label).

If you wouldn't mind sharing I'd be interested in seeing/using this. Currently I have a filter in gmail that matches emails that are from myself and have "rss" in them, which paired with a dedicated sendmail listening on my computer (opensmtpd, I'd highly recommend checking it out) has lead to me getting 100%. Your method sounds interesting though!

Does anybody offer an encrypted-on-the-server email setup which allows easy key revocation? It's desirable (revoke a key you used on your iPhone when you sell it, or use a key a single time from an untrusted PC, etc.), but really inconvenient because each email would need to be encrypted for each key. And when you create a new key, if you want to read emails sent before the key's creation you'll need some way for the server to go back and reencrypt all the older emails, etc. Seems like a can of worms, but it'd be awesome if someone somehow made it convenient. I might just be wishing for magic, though.

EDIT: 'Sup with the downvote? Explain what's wrong with my post.

There is also the option of running your own mail server, and encrypting mail as it is delivered:

https://grepular.com/Automatically_Encrypting_all_Incoming_E...

Doesn't this make your key susceptible to known-plaintext attacks?

That I guess would depend on the algo for the PGP key in question. The default these days is RSA 2048 for gpg, which as far as I know is not vulnerable to known plaintext attacks.

The trouble is, if you use the same key to encrypt the same plaintext, you'll get the same ciphertext. Then an eavesdropper can compare the ciphertext you sent her with the ciphertext you sent someone else and see if they are the same.

This is why all worthwhile encryption schemes are nondeterministic, incorporating randomness. If you encrypt the same data twice with GPG, the results will not be the same.

No. GPG doesn't use the public key to do the actual encryption, it generates an intermediate key, uses that to encrypt the message and encrypts that intermediate key with your public key.

Maybe this is too far-fetched and it's beyond what is technically possible today, but wouldn't the decrypted message be the plaintext for the session key and wouldn't then the session key basically be the plaintext for the public key? I suppose it's considered unbreakable because you only get one plaintext per session key?

How would that work?

Interesting concept. You should probably add some try/except blocks around parts of it though, specifically around this area:

result, data = mail.search(None,'(NOT BODY "BEGIN PGP MESSAGE")') ids = data[0] id_list = ids.split()

There's a chance "result" will indicate a failure and/or "data" will be None, causing the access to data[0] to throw an exception.

I haven't looked into what the API returns for "result" so I can't speculate on a fix, but I'm sure it should be easily handled.

Suggestion - Add a very concise screencast with audio walking an average person through setting this up.

Funny … I've been writing a python script that uses IMAP IDLE to monitor your inbox and encrypt incoming email (while retaining from/subject/date) and delete the plaintext version.

Unfortunately sometimes the IDLE errors and I haven't been able to figure out why. And I've yet to get Gmail to actually delete the email (vs just moving it to the trash)

I think I've run into this exact same problem with the delete, it reports that the flag has been set, but post expunge, nothing has happened to the message in question.

I'm still looking into it.

FWIW: https://github.com/mannkind/IMAPEncrypt

It works, but it's cobbled together and still has some issues I haven't been able to resolve.

Hey just wanted to give my thanks to you on this, using your code as a guide I was able to add the imap append level functionality I had been holding out on due to not wanting to mess with the nightmare of MIME encoding and walking through multipart attachments et al. Thanks, you saved me a ton of time there.

How would this be any better than downloading all emails, encrypting them and deleting the original off the server?

That's exactly what this does, except it puts them back, too.

A slightly better, but still lacking solution is to run your own mailserver and encrypt all incoming messages, something like this https://perot.me/encrypt-specific-incoming-emails-using-dove... simple enough for any HN reader to handle.

It of course still doesn't keep out the scary folks, as they'll just tap the network beforehand, but it does raise the bar quite a bit from other 3rd parties snooping. Combine with a crypto-stick, https://www.crypto-stick.com/, and good practices on the mail server and you're in the best shape anyone can be until everyone encrypts their outgoing email.

This is great! I will run it before I close my gmail account just for fun.

I like the idea of this. Yes, it doesn't encrypt the message from sender to you, but then you require the cooperation of the sender for that.

I think I will do this. I was thinking of downloading all my gmail to my local anyways and then deleting them since emails over 180 days old don't require a warrant to read right?

Thank you for creating this.

For "at-rest" Google Drive encryption syncdocs works well. No unencrypted files are ever stored on Google Drive.

http://www.syncdocs.com/syncdocs-screenshots/how-to-encrypt-...

Even if there were a perfect solution for storing encrypted email it would still be unworkable because you'd lose the ability to search your email. It seems like too big of a feature to lose. Have crypto people come up with a solution for building encrypted search indexes?

There's an interesting interview with Julian Fay of Senetas @ http://risky.biz/RB282 discussing homomorphic encryption. (Also mentioned in a couple of comments above.)

I'm getting an occasional "TypeError: 'NoneType' object is not subscriptable." Added try/except, and it works like a dream on 99% of the emails. I'll just run it twice :)

Reply on news.ycombinator.com