If you send an email to someone without Tutanota. They email the recipient with a link to their server. Allowing the recipient to decrypt the email in the browser, using a password agreed on, by the communicating parties.[0]
There is some voodoo in there about them storing your unencrypted mail encrypted on their server, but from that diagram it looks like it's only end to end between people registered with Tutanota (it looks like they may also allow federation, since they mention "or another service").
That is simply not true. We have a very high degree of Tor users. Unfortunately, some spammers also hide behind Tor. That is why we disable accounts that are used for spamming purposes.
You can always contact our support if you feel that your account has been disabled without reason. We check every case... :)
What extra do the encrypted messaging services offer on top of say, forcing a regular mail server to only user tls1.2. Must we all move onto a single provider?
I'm just curious why that's not good enough where sysadmins collectively pester whoever they require secure communication with to also have a tls1.2 mailserver. Would that not be job done?
Forcing TLS for the MTA at each end is about network encryption (i.e. akin to HTTPS) this "solution" is about encrypting the contents of the message envelope, i.e. restricting who can read the contents of the message regardless of how its transferred.
As I mentioned elsewhere, it is however yet another non-solution, for the same reason you queried - it's all reliant on a single provider.
Real end-to-end encrypted email is when your mail client uses either S/MIME or PGP/GPG to encrypt your message using the recipient's public key(s). In that situation, it doesn't matter what mail service they use, or what network transport the MTA's use - it's readable only by them (well technically only by anyone with the appropriate private key - I'm going to assume people are protecting their keys).
That would not be end-to-end. Email is a store-and-forward service, so even if you guarantee that every network hop is protected, the message is in cleartext (and thus inspectable, alterable and censorable) on every server.
So yet another "end to end encrypted" email "solution", where both ends are controlled by a single vendor.
There are already two, count them, TWO, existing, open, well-understood ways to both sign and encrypt email between two parties: PGP, and S/MIME.
Currently, the UX around setting up and using each of these tools is.. less than stellar.
Now. Just go with me here. What if all the people who keep claiming to have "solved the encryption problem" by locking everyone into their own little silo, instead of doing that, WORKED ON SOLVING THE USABILITY PROBLEMS?
Please don't post snarky 'yet another' dismissals in response to new work. We're trying for more thoughtful discourse than that here. It's fine, of course, to ask what's new or how something differs from another instance in its class.
In that it claims to be 'end to end' encryption, but that both 'ends' are from the same vendor, it's exactly the same.
So if you use protonmail and your colleague uses this, and you want to have a secure conversation over email, you're each going to be clicking clicking a fuck load of "view this message on <service you don't use>" links.
[+] [-] DavideNL|10 years ago|reply
If their servers disappear for whatever reason (legal issues or hardware problems), you end up with 0 e-mails. Nothing.
[+] [-] Flimm|10 years ago|reply
Is this promising end-to-end encryption over email even if one of the two parties is not using Tutanota?
[+] [-] mr_sturd|10 years ago|reply
[0]-https://tutanota.uservoice.com/knowledgebase/articles/470795...
[+] [-] x1798DE|10 years ago|reply
There is some voodoo in there about them storing your unencrypted mail encrypted on their server, but from that diagram it looks like it's only end to end between people registered with Tutanota (it looks like they may also allow federation, since they mention "or another service").
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] g4k|10 years ago|reply
[+] [-] troublord|10 years ago|reply
[+] [-] mirimir|10 years ago|reply
[+] [-] troublord|10 years ago|reply
You can always contact our support if you feel that your account has been disabled without reason. We check every case... :)
-- Matthias Founder tutanota.com
[+] [-] Already__Taken|10 years ago|reply
I'm just curious why that's not good enough where sysadmins collectively pester whoever they require secure communication with to also have a tls1.2 mailserver. Would that not be job done?
[+] [-] stephenr|10 years ago|reply
As I mentioned elsewhere, it is however yet another non-solution, for the same reason you queried - it's all reliant on a single provider.
Real end-to-end encrypted email is when your mail client uses either S/MIME or PGP/GPG to encrypt your message using the recipient's public key(s). In that situation, it doesn't matter what mail service they use, or what network transport the MTA's use - it's readable only by them (well technically only by anyone with the appropriate private key - I'm going to assume people are protecting their keys).
[+] [-] dsr_|10 years ago|reply
[+] [-] stephenr|10 years ago|reply
There are already two, count them, TWO, existing, open, well-understood ways to both sign and encrypt email between two parties: PGP, and S/MIME.
Currently, the UX around setting up and using each of these tools is.. less than stellar.
Now. Just go with me here. What if all the people who keep claiming to have "solved the encryption problem" by locking everyone into their own little silo, instead of doing that, WORKED ON SOLVING THE USABILITY PROBLEMS?
[+] [-] vox_mollis|10 years ago|reply
Use cases exist in which you need to communicate securely and authenticated, but can NOT leak the above.
Some combination of Pond( message inboxes, timestamp randomization ) and Ricochet( authentication, origin/destination obfuscation ) is sorely needed.
[+] [-] dang|10 years ago|reply
Also, please don't use all caps for emphasis. That's in the site guidelines: https://news.ycombinator.com/newsguidelines.html
[+] [-] muloka|10 years ago|reply
Are there security considerations between each solution that they took into account when deciding?
[+] [-] steaminghacker|10 years ago|reply
[+] [-] stephenr|10 years ago|reply
So if you use protonmail and your colleague uses this, and you want to have a secure conversation over email, you're each going to be clicking clicking a fuck load of "view this message on <service you don't use>" links.