3 ms·

Yes, it is. But if this is a feature of a mail service rather than a mail client, then the service has the keys and, given GPG has no perfect forward secrecy,

Yes, it is. But if this is a feature of a mail service rather than a mail client, then the service has the keys and, given GPG has no perfect forward secrecy, they have the ability to decrypt all emails you send and recieve. If you go down the road of the mail service owning a mail client that promises e2e, then the issue moves to worrying about the code that runs on your device. If it's webmail, the JavaScript can easily be changed, so you really want a thick client. Then you need to worry about the thick client sending data that it's really not supposed to i.e. can it read your key and send it to $vendor? Even then, GPG without Perfect Forward Secrecy means that when your key is brute forced or side channel attacked, which we assume will happen, you lose all your secrecy, so you need to think about this as a temporary state.

bad_user 8y ago
Note that the key could be client side and the email service could encrypt the email in a way as to not find out your private key. However, and this is key, a majority of email is sent and received unencrypted via their servers, because that's just how email works. In other words, email at rest might be encrypted, but most of the email in transit is not. This means that a man in the middle (e.g. the NSA) can still intercept all your communications. And even with PGP encryption, which is e2e, the meta data is still unencrypted because that's what the email protocol demands. Having the ability to see whom you're communicating with, that's enough in many cases. Email is simply not a good solution for e2e encryption. If you have secrets to protect, there are now other solutions available, like Signal and even Signal has some issues (like its reliance on phone numbers for identification).