
Automatically encrypt your Gmail account - etherael
https://github.com/etherael/Phoneme
======
theboywho
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.

~~~
themckman
> 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?

~~~
dhimes
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...](http://en.wikipedia.org/wiki/File:Upstream_slide_of_the_PRISM_presentation.jpg)

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.

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

------
methehack
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 :)

~~~
cool-RR
You lose backend search this way. It's a critical feature.

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

~~~
michaelt
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).

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

~~~
etherael
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.
:)

~~~
lemming
What about just modifying GMVault to do this?

~~~
etherael
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?

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

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

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

------
mike-cardwell
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...](https://grepular.com/Automatically_Encrypting_all_Incoming_Email)

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

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

~~~
wkornewald
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?

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

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

------
mannkind
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)

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

~~~
mannkind
FWIW:
[https://github.com/mannkind/IMAPEncrypt](https://github.com/mannkind/IMAPEncrypt)

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

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

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

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

------
dpeck
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...](https://perot.me/encrypt-specific-incoming-emails-using-dovecot-and-
sieve) 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/](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.

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

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

------
CPAhem
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-...](http://www.syncdocs.com/syncdocs-screenshots/how-to-encrypt-
google-drive-files-and-docs/)

------
guelo
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?

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

------
hellcow
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 :)

