Not technically. You'd just have to apply encryption at a higher level
Send email bodies encrypted to base64 along with a public key fingerprint, then receiver's client would decrypt if it had the private key for that fingerprint
But this isn't compelling enough to get a network effect to topple in-browser gmail
Common misconception. The three letter agencies do not really need to know the contents of your email body. They're much more interested in to/from, timestamps, and subject. Establishing that you communicate with a person and then getting their emails is much easier than playing with your encrypted email body.
I think this is a common misconception of its own. The three letter agencies would love to be able to see the content of messages. But the code makers have run so far ahead of the code breakers that this is effectively impossible. So they settle for only meta information and tell the people that are funding them that this is now sufficient for them to continue to do their job.
You have a misconception yourself, and it shows. It depends on what they're after. If they want to see an individual's email then obviously they need to decrypt the body.
People routinely do end to end encryption with email every day using either OpenPGP or S/MIME. Heck, email encryption is where the term "end to end encryption" came from. When someone claims E2EE for some other sort of messaging system they have to at least be as good at it as the email case to be taken seriously.
> People routinely do end to end encryption with email every day using either OpenPGP or S/MIME.
Those solutions encrypt only the content and not the headers, which are just as important. Also, encrypting the content prevents some webmail services from functioning, such as search.
> Those solutions encrypt only the content and not the headers, which are just as important.
There are implementations which encrypt the headers, for example Delta Chat, which says[0] in its FAQ:
'Many other e-mail headers, in particular the “Subject” header, are end-to-end-encryption protected, see also this upcoming IETF RFC.'
If you mean that the sender's server and the recipient's server can see the recipient's and sender's (respectively) addresses, then I would say that this is equivalent to most other "end to end encrypted" messaging apps, which usually rely on a trusted third party to connect the two ends.
In fact, I would argue that the situation with email is better, because although Alice and Bob's providers might know that they are communicating with each other, Carol's provider will have no record of this at all (and Alice and Bob may not know that Carol or her provider exists).
The situation with email could be made even better than that, though, since email servers could provide a dedicated "switchboard" address, such that Alice sends her email for Bob as an encrypted inner-message of an email sent to Bob's server's switchboard address. That way Alice's server wouldn't know who the intended recipient was, only their server address. Similarly Alice's server could rewrite the headers of her outer-message so that Bob's server doesn't know that Alice was the original sender. This would effectively implement a type of anonymous remailer.[1]
> encrypting the content prevents some webmail services from functioning, such as search.
You've shifted the goalposts here from "email can't be secure" to "webmail can't be secure". In any case, I disagree. It is possible to implement a client-side full text search[2], even if it means decrypting the index for every search, and re-encrypting the index whenever a new email is added to it.
This is bad advice, which could be dangerous for some. Look around for what actual security experts recommend: It's not email, and it's specifically to not use email. It's not a debate; it's universal afaik.
The headers are mostly protected with the TLS used for the connections between the server and the clients and other servers. Email is no worse than most things these days and better than many.
Anyone who's worked on the PGP project would be the first to tell you that PGP does not and cannot encrypt the email's metadata (to/from, subject, timestamps, etc).
All PGP does is encrypt the inner message body. All of the metadata that TLAs love to analyze is sent in the clear (at best inside a TLS connection, although the SMTP protocol unfortunately makes it incredibly easy for well-positioned network attackers to downgrade these connections to in the clear)
None of this has anything to do with the incorrectness of the assertion that PGP would “beg to differ” that end-to-end encryption of email is impossible. Playing 3-card monty with your message is something else entirely.
Send email bodies encrypted to base64 along with a public key fingerprint, then receiver's client would decrypt if it had the private key for that fingerprint
But this isn't compelling enough to get a network effect to topple in-browser gmail