The email stored on T/P is not end-to-end encrypted. T/P have access to it without going through you. Why? Because that’s how email works. When receiving mail, their server is contacted by another (non-encrypted) server who says “I have a message for you, accept it and store it”. And they have to be able to do that 24/7 without involving you. Same for sending, they have to take your message and store it for several days until they can send it out in clear and another (non-encrypted) server has confirmed it has accepted it. Any pretense that any of this is secure is just security theater.
You cannot have multiple clients on multiple devices, because they’ve replaced standard protocols (IMAP and SMTP) with their proprietary wrappers to maintain the pretense. So you can only use their apps (insofar as they’re available for your devices), or their webmail, that know how to speak the proprietary protocols. This locks you into their service.
You can’t do secure email. You really can’t, sorry. Point (1) above is a game-ending design flaw that makes it impossible, and (2) is just lock-in and hoops to jump through without really adding anything of value.
You could do remote encrypted storage of your email archive but only if you give up the notion that you can also allow that storage server to send and receive messages for you. If they have access then it can be subverted and the whole proposition is worthless.
The way to achieve such storage is by using a remote file storage service reflected locally as a virtual filesystem, preferably with the encryption layer controlled by your device not their service, and use it to store messages managed by your local email client. Your local email client would then use IMAP and SMTP connections to unrelated email servers to send/receive messages. But you’d have to replicate this stack on every device, which is impractical.
The better approach is to self-host your mail archive, with a webmail client on top connected to a SMTP service, and have a local tool on the server that pulls emails from a POP3 server and deletes them afterward. And you can encrypt the disk there if you want, and use whatever you want to access your archive (regular email clients or webmail).
I disagree with 2. Tuta works on multiple devices at the same time. Empirically
A. My point about having all data at rest encrypted still stands.
Depending on your threat model, having properties one, and a are sufficient. All of your historic data encrypted at rest has value for people.
I also agree with your statement about keeping all of your mail history local on an encrypted drive. That would also work. But you lose the cloud aspect of having a completely client-side encrypted service provider
Clearly tuta doesn’t fit your threat/usage model. But it does work and does provide a valuable service/trade off for people who want cloud based client side encryption for data at rest.
PGP is not particularly related to email. It’s also used to encrypt files, partitions etc.
You can use public key cryptography with any system, because you simply encrypt the content and then send it through the normal unencrypted system.
But PGP does nothing for the headers and nothing for the fact messages are still waiting around on various servers. Also PGP on its own is very impractical due to the need to get keys for every recipient – but even if there were a generalized system of public key autodiscovery (over DNS) it still wouldn’t fix the problems with IMAP/POP3/SMTP.
Each of these things holds a piece of the puzzle – including what Proton & Tuta are doing – but these pieces on their own are useless. We need all of them to come together.
You can’t do secure email. You really can’t, sorry. Point (1) above is a game-ending design flaw that makes it impossible, and (2) is just lock-in and hoops to jump through without really adding anything of value.
You could do remote encrypted storage of your email archive but only if you give up the notion that you can also allow that storage server to send and receive messages for you. If they have access then it can be subverted and the whole proposition is worthless.
The way to achieve such storage is by using a remote file storage service reflected locally as a virtual filesystem, preferably with the encryption layer controlled by your device not their service, and use it to store messages managed by your local email client. Your local email client would then use IMAP and SMTP connections to unrelated email servers to send/receive messages. But you’d have to replicate this stack on every device, which is impractical.
The better approach is to self-host your mail archive, with a webmail client on top connected to a SMTP service, and have a local tool on the server that pulls emails from a POP3 server and deletes them afterward. And you can encrypt the disk there if you want, and use whatever you want to access your archive (regular email clients or webmail).
I agree with 1.
I disagree with 2. Tuta works on multiple devices at the same time. Empirically
A. My point about having all data at rest encrypted still stands.
Depending on your threat model, having properties one, and a are sufficient. All of your historic data encrypted at rest has value for people.
I also agree with your statement about keeping all of your mail history local on an encrypted drive. That would also work. But you lose the cloud aspect of having a completely client-side encrypted service provider
Clearly tuta doesn’t fit your threat/usage model. But it does work and does provide a valuable service/trade off for people who want cloud based client side encryption for data at rest.
Just because Tuta and Proton don’t rub you the right way doesn’t mean they’re not valid options, stop FUDing around.
PGP would like a word.
Which part do you think it’s FUD, and why?
PGP is not particularly related to email. It’s also used to encrypt files, partitions etc.
You can use public key cryptography with any system, because you simply encrypt the content and then send it through the normal unencrypted system.
But PGP does nothing for the headers and nothing for the fact messages are still waiting around on various servers. Also PGP on its own is very impractical due to the need to get keys for every recipient – but even if there were a generalized system of public key autodiscovery (over DNS) it still wouldn’t fix the problems with IMAP/POP3/SMTP.
Each of these things holds a piece of the puzzle – including what Proton & Tuta are doing – but these pieces on their own are useless. We need all of them to come together.