I’m reading about several services’ implementations of encrypting your emails on their servers (not talking about E2E encryption, but encryption at rest) and I’m confused about some things.
How do various providers do this? Proton does it like this
But then I read mailbox’s implementation encrypts your mailbox with PGP.
Can someone guide me as to the technical differences between these implementations and what implementations other services like Tuta and posteo use?
And how do these implementations affect the decryption process when you need to access your unencrypted mailbox? Does the decryption happen on the server and you get sent the message (keeping just messages in context here for simplicity, because I know other things can be encrypted by certain providers) unencrypted or do you get sent the encrypted messages to your app/browser and using the private key to decrypt locally? If it’s the former what are the conditions that the messages stay unencrypted on the server? Is it until your sessions ends? What about being logged in to the app on your phone? Does that make your emails being unencrypted server side for as long as you’re logged in with the app?
Also the fact that services store the private key encrypted on their servers, what are the conditions where the private key stays unencrypted after being decrypted with your password?
Excuse any wrong assumptions since I’m not very educated about the technicalities about these mechanisms, hence why I’m here
My understanding is that all of Proton, Mailbox and Posteo encrypt your emails with zero access encryption (it’s the default for Proton with no option to turn it off, but an option for others that’s off by default) using PGP. They store both your public and private keys but encrypt your private key with your password (which should never be known to them), so they in effect don’t know your private key. When you sign in with your password, their servers send you your private key, and you decrypt it locally. You then use it to decrypt emails they store locally.
Tuta uses their own encryption, which should be more robust (encrypts more metadata, and is also post quantum). Posteo also offers another way of encryption, which is better than PGP because it encrypts everything, but I believe it’s not post quantum.
Thanks for the informative reply. So PGP (or Tuta’s closed implementation) is also used for zero access encryption and not just for E2EE. Interested to read about the Posteo option now and will do so, so thanks for the link.
So I’m assuming that’s why we need Proton Bridge to use other mail clients on desktop then. To decrypt locally. And I’m guessing the Proton Mobile apps do the same thing but in one app. As for Tuta they only have the Mobile app that does that apart from webmail app of course. So both of these services won’t be able to use POP3/IMAP without that ‘bridge’ (whether it’s webapp javascript or local app with ‘bridge’ software if they have it).
So my next question is, in mailbox.org website and the PG email recommendation page, it is stated that they support POP3/IMAP through a .onion exit node that they host themselves and that they support “standard access protocols like IMAP and POP3” according to PG. How does the decryption with the private key happen in such cases? I’m assuming that through the .onion service there’s code implemented to send the private key to the browser and decryption is done locally, but what about the statement that they support “standard access protocols like IMAP and POP3”? Is that with third party apps like Thunderbird? Asking because decryption can’t be done locally that way.
My understanding is that not all ‘encryption at rest’ is ‘zero knowledge’. In some (most?) cases of ‘encryption at rest’ the email provider holds the encryption keys and technically has access to your emails. I guess this is for security in case of unauthorised access to the servers?
I’m happy to be corrected! Maybe someone with more knowledge could clarify this for me?
That’s a great question, but just to be clear, Tuta’s encryption is open source. I assumed you meant closed in a different way, but I still feel like I should clarify this.
There’s no technical reason Proton don’t support IMAP. They could do a similar thing to what Mailbox does. Mailbox delivers PGP encrypted mail to your IMAP mail client, and it is your responsibility to decrypt it. They allow you to export your private key, and you can then use it to decrypt the mail through a client that supports PGP (eg thunderbird), or through a standalone program (eg openkeychain).
Tuta can do the same theoretically, but there is no support for its encryption outside their clients, so someone would need to make an app that can decrypt their mail.
Keep in mind that I never used Mailbox, so this is just my personal understanding of how this works.
I’m a mailbox.org user, I can explain my setup, maybe it helps you.
There are two ways to manage your encryption keys in mailbox.org:
Mailbox.org generates the private and public key, and they store both private e public key on their servers (and use your password to decrypt), this is so far the easiest way for those who are not familiar with PGP.
You manage your private key, this is the favourite option for those who are familiar with PGP
I’m using the second option, I generated the private key on my computer, via gnupg and I keep the private key only on my computer, I haven’t uploaded the private key to the mailbox.org server.
How to encrypt all incoming emails?
Simply upload your public key to a mail Sieve rule, this rule must always be the first one. Whenever you receive any email, the Sieve rule will automatically encrypt and store the email encrypted in your mailbox. Note, you just need your public key.
How to read your e-mails
If you’re using an email client like Thunderbird, you can configure it to automatically decrypt all your messages, it’s transparent and works very well. This is how I use it.
If you want to use webmail, then you need to configure mailenvelope (Firefox plugin) to decrypt your messages.
The second option is not easier as letting Mailbox.org to manage your key, but it’s not a problem for me. Once the setup is done, everything is easy and transparent.
I hope it helps you
By the way, I’m also a Proton user. Proton is my primary email and Mailbox.org is my secondary email, as a kind of redundancy. Both services are great.
What would post quantum comprise of in terms of encryption? Are there particular algorithms in encryption? I’d love to know more about that as I see the term often
That’s great info thanks! I like the option of the user having more control tbh. I’m assuming mailbox.org lets you decide where to generate the keys at sign up then? Or is encryption not enables by default and you choose to encrypt later?
This is how it should be done tbh. Giving the user choice.
This is an interesting problem to solve, while keeping interoperability. I’m not familiar with the mechanics of PGP in email to know if changes should be made upstream or if it’s an email protocol limitation that doesn’t let the email header be encrypted with PGP. Any good literature about that topic? Did Tuta ever openly publish their approach?
Edit: just saw your second link. Thats a good read
I’ve been using Mailbox for a couple of years, I don’t really remember the initial setup, but if I remember correctly, encryption is not enabled by default.
Post quantum encryption is all theoretical until quantum decryption becomes possible.
In theory, there are three algorithms that should be resistant to quantum decryption. A year or two ago we had 4, but then one got Pwned by math nerds.
I know one of them is available for PGP, I saw it when generating keys in kleopatra.
Encryption in transit: the mail can’t be read by anyone while it’s travelling between the sender’s and recipient’s mail provider servers. So if you send an email from Yahoo to Gmail it means the ISP or a government can’t read the email while it’s on its way. This is implemented in almost all email providers.
Encryption at rest: the mail is encrypted while it’s stored on the server of your mail provider. But the provider still has the key to decrypt the emails. For example if someone hacks your mail provider or physically breaks into their data centre or a rogue employee can’t “just” read your emails. But if the police comes knocking they can request access. Some providers might also read your mail for targeted ads. The majority, but not all providers, implement this encryption.
Zero knowledge encryption: when an email arrives it is immediately encrypted with a key only you possess, same with the emails you are sending out. So your Inbox and Sent folders are encrypted at rest but in a way that only you can read the emails. Protonmail, Tuta or Mailbox.org support this kind of encryption. But when you communicate with someone using a “normal” provider like Gmail or Hotmail then the emails are still unencrypted when they arrive at your provider’s server or when you send an email out. So it’s still technically possible to intercept the emails in this moment and store an unencrypted copy somewhere. Tuta was asked by German police to intercept incoming (unencrypted) emails of a suspected criminal for example.
End-to-end encryption: this would be a special case where all servers support zero knowledge encryption, e.g. with PGP. So communication between two Protonmail users for example or two PGP users in general would be end-to-end encrypted with no possibility for the provider to read your emails at any point. Note that metadata (from, to, date, usually also subject) are not encrypted.
