So we're talking about after it's received and processed by a server.
> Email is built on top of plain text protocols and messages flow in plain text. If you encrypt, you cannot scan for spam or viruses...
But you can? Just scan and process before encrypting.
> ...index messages for searching
This indeed is a problem. Encrypting emails individually makes search difficult. Why not just encrypt entire hard drives? Encryption at rest is a very broad term.
> or recover messages when a password gets lost. Not to mention the usability issues of changing passwords and encryption keys.
This has nothing to do with email. This is encryption in general, and these security details are a feature.
> Some other providers automatically encrypt messages as they arrive using users’ public keys. That sounds exciting but in practice that means you cannot access your messages using the webmail unless you pasted your private key into a browser, and have it handled by script and a myriad of third party code. Ouch.
Huh? I haven't heard of copy-pasting private keys. Use passwords. But more importantly, this is specific to webmail, not email in general.
The title is throwing off how we’re reading the article. It’s really about why they, an email provider, can’t meaningfully encrypt email at rest. FTA:
>If you are interested in real encryption, please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself.
I would say their standard for being ‘encrypted at rest’ is including a requirement that they are unable to open it.
This is textbook ‘perfect being the enemy of the good’. There are a lot of threats outside of malicious insiders that could be deterred or slowed down by a practical encrypted storage mechanism.
yeah that gets clear when they talk about their certified physical security: there is a strong assumption that drives can not be stolen and will be destroyed at their EOL. Such assumptions often don't hold. Encryption and physical protection are not redundant, they are defense in depth.
I agree with the GPG part and that a mail provider can not reasonably create something similar, however they have a weird understanding of "encryption at rest" at the base of their argument why they don't do it.
In addition to protecting against losing hard drives, 'encryption at rest' (as applied in e.g. card industry) can also protect the data from an attacker who gets full access to the database through e.g. a SQL injection, if properly implemented.
> please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself
This is good advice but it just isn't going to happen in practice unless gmail makes it the default for everyone. WhatsApp added support for the Signal protocol and made it the default for all users, now the whole world is communicating with end-to-end encryption.
This is really a bad title to our Pro/Cons page, but in principle the takeaway here should be - email is not perfect and we chose some compromises (unless you use hey.com, they "fixed" email ;). That is why you are reading this as a Con to our service, not a Pro.
Indeed, for us, encryption at rest is only meaningful if we cannot access the mails either. However, that is nowhere on the horizon for email. There is a technical way to achieve that, but at a great cost of usability.
Encrypting the disks themselves is trivial and is on our roadmap, but it is nowhere as important as some providers tend to boast. That is why we say "quackery." It is just a "nice-to-have", but in every-day security it matters just as much keeping your car keys in a sealed jar all the time, carrying the jar in your pocket =)
Our data is stripped among multiple disks in RAID10 (obviously), that by itself ensures very little importance to a single disk. Not to mention that if a disk is dead, one would have to find it, identify it belongs to specific user and recover it. This is more likely:
Processes inside of the data center are way more important than an extra layer of encryption for a hollywood heist.
In our so far experience, the biggest threat to users' data are the users themselves. Forgetting passwords, accidentally deleting mails, running malware, choosing weak passwords...
It is interesting that we have never seen this issue raised for Outlook, Gmail, Zoho, Yahoo, AOL and other large providers, who never did or will encrypt at rest.
With hosted services there has to be a chain of trust. We trust our providers (ISP, data centers etc), and our users trust us as a provider.
Furthermore email is generally being observed wrongly today [IMHO]. Email message is a equivalent of an open envelope, a postcard. The only way to security is end-to-end encryption. This way, the need to trust the provider is removed. We could say openly we do have encryption at rest, but that claim cannot be proven by anyone. Same way as Whatsapp says they are E2EE but being a closed protocol, we still have to trust Whatsapp they are telling the truth.
As a provider you have to choose what is worth implementing and what not, what realistically benefits users and what not. Military grade security is silly for email in our opinion. If that is requirement, one should probably not be using email at all. Use Whatsapp :D
Jokes aside, we just try to keep a sane approach to security and not take absolutist stand, all or nothing. It is always a compromise between usability for the user, maintenability for the sys admin and cost. We are not on the expensive side meaning we have to take sane compromises.
If you are willing to pay a premium for absolute security, we can of course do that for you, but we know no one will be willing to pay, and those that do, we probably do not want to have such users, based on our experience from @protonmail users using Migadu. There is tutanota for that purpose btw.
Email was not meant to do many of the things we today try to use it for. It is much more complex than majority will even know and appreciate unless they become providers themselves.
Couldn't the indexing issue be solved by only having the client/user do the indexing while e-mails are stored encrypted on the server? Ideally on an encrypted device which will keep/maintain the indexing.
Shifting the burden of indexing e-mail (and decrypting/encrypting the at rest) on the client willing to achieve this?
Edit:
The webmail/imap/pop provider would only have to receive an e-mail and use a client provide public key to encrypt the mail and let it rest.
The webmail client could (in browser) or through their app do the decryption/indexing locally. Could be done with an extension.
But you can? Just scan and process before encrypting.
You can't. End-to-end encryption for email means the messages are encrypted by the sending client and decrypted by the receiving client. The server has no chance to scan anything because it cannot decrypt the messages.
Not clear if the author is referring specifically to mail services like gmail here. Full disk encryption would indeed encrypt my email at rest (assuming I'm syncing mail locally on my laptop with FDS turned on).
So we're talking about after it's received and processed by a server.
> Email is built on top of plain text protocols and messages flow in plain text. If you encrypt, you cannot scan for spam or viruses...
But you can? Just scan and process before encrypting.
> ...index messages for searching
This indeed is a problem. Encrypting emails individually makes search difficult. Why not just encrypt entire hard drives? Encryption at rest is a very broad term.
> or recover messages when a password gets lost. Not to mention the usability issues of changing passwords and encryption keys.
This has nothing to do with email. This is encryption in general, and these security details are a feature.
> Some other providers automatically encrypt messages as they arrive using users’ public keys. That sounds exciting but in practice that means you cannot access your messages using the webmail unless you pasted your private key into a browser, and have it handled by script and a myriad of third party code. Ouch.
Huh? I haven't heard of copy-pasting private keys. Use passwords. But more importantly, this is specific to webmail, not email in general.