Frankly, I can’t really wrap my head around what services like Proton and Tuta are trying to do, so in turn I can’t get a clear idea of the threat model.
They’re basically running encrypted file storage servers that are used to store email messages, forcing their users to use proprietary protocols to access them. But sending and receiving email messages implies messages passing through other, non-encrypted servers.
The only scenario where they’d approach anything resembling security is if both the recipient and sender are on the same service. Not even passing messages between two such services (Tuta & Proton) is really secure. And since the vast majority of the average user’s messages are exchanged with other servers it means that the vast majority of their messages have a copy in clear on at least one other server out there, and have passed through clear relays that are also not encrypted at rest, making more potential copies available.
So what exactly is solved by having one copy encrypted if there are non-encrypted copies readily available?
Data at rest. I totally agree for normal email usage patterns email is unencrypted. But most people have a massive multi-year backlog of archived messages. There’s no reason that can’t be encrypted.
The benefit tuta provides is the entire backlog is encrypted on disk, client side encrypted. That means you’re unencrypted exposure is only live messages, and not your backlog. It reduces your risk window.
It’s good data hygiene to keep all of your data at rest encrypted.
For the scenario where email is sent between two tuta users, The message is encrypted with the other users key and the service never sees the unencrypted message. But as you indicated that is a vanishingly small percentage of the population. And nowadays you would just use signal or simple x to message somebody securely directly. So email is definitely for the legacy world
This is equivalent to having full disc encryption, your email client always downloading all the email to disk and deleting it from the server. Your email archive is encrypted at rest. The difference here is it’s a cloud service provider, so you can have different clients on different devices all synchronized.
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.
Fair enough. The clients are open source, nothing’s preventing anybody from making a gateway if that’s the real desire.
Frankly, I can’t really wrap my head around what services like Proton and Tuta are trying to do, so in turn I can’t get a clear idea of the threat model.
They’re basically running encrypted file storage servers that are used to store email messages, forcing their users to use proprietary protocols to access them. But sending and receiving email messages implies messages passing through other, non-encrypted servers.
The only scenario where they’d approach anything resembling security is if both the recipient and sender are on the same service. Not even passing messages between two such services (Tuta & Proton) is really secure. And since the vast majority of the average user’s messages are exchanged with other servers it means that the vast majority of their messages have a copy in clear on at least one other server out there, and have passed through clear relays that are also not encrypted at rest, making more potential copies available.
So what exactly is solved by having one copy encrypted if there are non-encrypted copies readily available?
Data at rest. I totally agree for normal email usage patterns email is unencrypted. But most people have a massive multi-year backlog of archived messages. There’s no reason that can’t be encrypted.
The benefit tuta provides is the entire backlog is encrypted on disk, client side encrypted. That means you’re unencrypted exposure is only live messages, and not your backlog. It reduces your risk window.
It’s good data hygiene to keep all of your data at rest encrypted.
For the scenario where email is sent between two tuta users, The message is encrypted with the other users key and the service never sees the unencrypted message. But as you indicated that is a vanishingly small percentage of the population. And nowadays you would just use signal or simple x to message somebody securely directly. So email is definitely for the legacy world
This is equivalent to having full disc encryption, your email client always downloading all the email to disk and deleting it from the server. Your email archive is encrypted at rest. The difference here is it’s a cloud service provider, so you can have different clients on different devices all synchronized.
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.