Well, you should be able to encrypt the subject/body of the email without encrypting the headers, so the mail vendor never sees the content of the email, only the to/from addresses and such. But that encryption has to happen in the browser/application. ie Mailvelope plugin for Chrome and others like it. and I think there is an android mail client that will also do pgp/gpg encryption/decryption.
With email, you _can't_ encrypt the headers of message. Who the message is to, who it's from, when it was sent, what the subject line is... All those things need to be accessible to every server that touches the message from creation to delivery.
Things get worse when you have to interoperate with mail clients that don't support encryption. Now the best you can do is encrypt the body of the message at rest, but you still have to be able to decrypt it to deliver it.
You're absolutely right that _if_ both parties are using PGP in their clients, then the _body_ of the email will be secure, end to end (not the meta data mind you, just the body). However, that requires a lot of manual key management (assuming you use a client that supports it in the first place). That key management nightmare is why no one actually uses PGP...
Email is not safe, by design. Even if you do encrypt the contents using PGP or GPG, the headers are too much exposure. They will know who when and with whom you correspond, and all the hosts the mail passed through (if you are not using anonymous re-mailers). The current implementation of email is "defective by design". But _there_are_ alternatives [1], you must just start using them.
[1] RetroShare, BitMessage, I2P Bote, Freenet + Frost and some others, which haven't tried yet.
Governments can still gather the metadata of encrypted emails. Both PGP and S/MIME do not encrypt the subject line, sender or recipient addresses.
To use encrypted email and hide the subject line, you need to not use it (just say "Encrypted email") or something. This cannot be made automatic without impacting UX.
The To: header fundamentally cannot be removed. The sender can be inferred from the account within the email provider supplying the Government's feed.
I like the idea for MUAs to automatically encrypt after a mutual automatic key exchange though. I think PGP would be more suitable for this (no CAs required). Is there a standard email header that advertises "you can reply back to me with a PGP encrypted email encrypted to key ID X and I'll be able to read it automatically"? If not, somebody should propose one. Public keyservers exist so I see no reason a simple header like this wouldn't suffice. The rest is MUA implementation.
It should be possible to go a step further, though, if mail providers offered a well-known reserved address like switchboard@domain which Alice could send an encrypted email to, and it would decrypt it to determine that the intended recipient was bob@domain. Ideally, Alice's mail provider would rewrite the sender headers to something generic too, relying on Bob to extract those from the email he decrypts.
That way the sending server would only know the recipient server (not the local-part of the recipient address) and the recipient server would only know the sending server (not the local-part of the sender).
Of course, this would make server-side spam filtering much harder, so it would benefit from some sort of bearer token system for bypassing such filters. The Autocrypt standard already uses special headers for signalling state between sender and recipient, but this header would require the mail provider to detect the new header and change their filtering rules based on it.
You could pgp encrypt anything that you really don't to be read in transit. Short of that, you might as well assume that your emails are being read and stored by third parties.
Even if you personally use the most secure email server in the world, it doesn't matter because everyone that you send email to or from is likely using hosted services like gmail, verizon, hotmail, etc.
> We'll try to make that more clear in the received (encrypted) emails
This seems like the ideal. If the message could look like
> This message from mom@protonmail.com was encrypted by PGP using the public key for foo@gmail.com retrieved from www.keys.openpgp.org
> -- BEGIN PGP MESSAGE --
...
Would that leak anything the email provider and every forwarding server couldn't already have known? Not sure if clients support this kind of mix of plaintext and PGP: of course you could put the metadata in the headers, but clients won't show random new headers by default and Google isn't going to help you encrypt messages they would prefer to read.
There's nothing about Gmail that prevents you from encrypting your subject lines.
The most important metadata however is whom your communicating with. And there's nothing in GPG that can protect the addresses of your recipients, because it's not possible due to the email protocol.
This is basically just plain gpg+email done via a browser extension. So no protection of metadata (headers), no indexing of body (by upstream provider).
So if you have (potentially sensitive) information in the subject, you can search on that, and on to/from/cc etc -- but not on email body. Only way to achieve that securely, would be to have an encrypted index (that might be stored in an IMAP folder, encrypted) and decrypt and search it locally. At that point you are doing something rather different from what gmail is (currently) doing, however (I believe mailpile does something along those lines).
I guess I don’t understand why you would think that the following wouldn’t work:
- use random email addresses
- encrypt the content with something more secure than PGP (on the client)
- receive the email and decrypt it (on the client)
Sure, it’s plaintext, but I don’t see the downside?
> Someone using a Gmail account sends an email to a ProtonMail account. When it arrives at ProtonMail, our servers can read that email because Gmail does not support end-to-end encryption. However, after receiving the email, we encrypt it immediately using the ProtonMail account owner’s public encryption key. Afterwards, we are no longer able to decrypt the message.
It's noted that they can potentially read it but they encrypt it right away. I'm not saying that they have the functionality to read it in that step, I'm saying they could add it if they chose to. It's their code, after all.
> I guess if you're not going to trust anyone (and personally I'd trust ProtonMail based on their honest blog posts, security responses and response to security blog posts criticising their work) then you'd want to self-host. But I'd argue at that point email isn't the solution you're looking for.
I think you're reading too much into my post. I'm saying that the potential exists for the provider to read the messages, simply because email is a plaintext protocol (outside of things like GPG and S/MIME which I insinuated but didn't actually mention). I do, however, agree with you that if you don't want to trust anyone than other solutions would be more beneficial.
Google cannot implement what you’re proposing (nor can any email provider). Whatever mail service you choose must be able to send and receive email on your behalf and to do this, they must have access to the email in unencrypted form [1]. Yes, they could encrypt at rest. And yes, they could even encrypt with your public key at rest. This doesn’t eliminate the need to completely trust them [2] but it does completely break critical features like search and a usable mail archive.
[1] Yes, if you use gpg and the party you’re communicating does as well, then you don’t need to trust the email service. Good luck with that.
[2] If you can’t trust them to not look at your email then you can’t trust that they’ll actually encrypt without keeping a copy (or that they’ll actually encrypt at all). Encryption at rest is a great feature, but not for eliminating the need to trust the organization running the email service.
I'd like to, but it's too much trouble and noone else doesn't so it's pointless..
To echo some of the comments here, I think the main factors making this (PGP, GPG usage) unfeasible at the moment is:
1) Too hard for casual users (=others don't use it)
2) PGP/GPG is ridiculously difficult when using webmail or mobile email clients.
3) Your email usabiliy suffers. With this I'm referring to your ability to search your emails. Once you are using encryption, you can't find anything in it, unless the email is decrypted and saved plain in your email storage.
The usability part is actually forgotten quite a few times in discussion, but I think it's a big problem. If you opt to decrypt and save it, this would be ok, if it happens on your client (local db), but not stored remotely (eg. webmail/imap box). This problem comes with a whole lot of issues attached.
PGP is not necessarily "unusable" on Mobile. I use K-9 Mail + APG (both free) on Android, and can read and write inline PGP signed/encrypted mail. It's a shame there's no PGP/MIME support though.
But there's also server side encryption that is end to end. If both the sender and recipient uses a trusted mail server that uses encryption then nobody between the two can see the email.
Nice, yes, thanks the reply, agree with everything.
> This process only encrypts the email's body, and not the metadata (from, to, subject, headers containing IP addresses, etc). As a bunch of people have shown after the PRISM fallout, analysis on metadata alone can reveal an incredible amount of private information.
I also had the idea to have encrypted containers something akin to what you are proposing, with PGP for the body underneath. It gets complicated..
Anyway,
> Of course any solution to this problem will be a compromise between security and usability, so let's hope a number of different solutions will see the light of day, so that everyone can choose the solution that works the best for them.
I very much agree. Here's to hoping to see multiple solutions soon :)
Just use PGP, but keep in mind headers won't be encrypted.
If it doesn't fit your bill, just give up and use other methods of communication that aren't email. Email just wasn't built for this sort of purpose in mind.
reply