Tutonota: An end-to-end encrypted email client and hosted service
github.com
github.com
If their servers disappear for whatever reason (legal issues or hardware problems), you end up with 0 e-mails. Nothing.
Is this promising end-to-end encryption over email even if one of the two parties is not using Tutanota?
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").
As for the "encrypted mailbox", what you are describing sounds to me like the decryption is done client-side using javascript (unless the recipient needs to download something in order to decrypt the mail), in which case I would consider that to be essentially insecure anyway, as that is also a "promise not to look". It's the same situation as Protonmail, which I personally consider to be crypto snakeoil.
You can use apps (iOS and Android) and even compile and install the client locally if you want to.
There will also be apps for Windows and MacOS in the future.
If you mean a local server using the github code, it's a fair enough point - it's more complicated and likely insecure than using PGP, but at least the burden of complexity and security falls on the power user.
Presumably that passphrase would be shared out-of-band to prevent Tutanota peeking, at which point... Why bother sending an e-mail at all?
[0]-https://tutanota.uservoice.com/knowledgebase/articles/470795...
In addition to not having forward secrecy (if a 3rd party gets his crypto password, they get ALL of my messages to him), this seems to fail the classic "In order to exchange a secret, first exchange a secret" crypto usability test.
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
But I've had it happen more than once, without warning, and without any mail sent.
Also, contacting support isn't really a viable option, for new personas with no other email address.
We will change this, if there is a better way that provides protection against spammers...
But is spamming through Tor really such a huge problem? I vaguely recall the argument that there wasn't enough bandwidth. And maybe there is now, with faster relays.
But it still seems like overkill to nuke new accounts that you consider suspicious, before they've even been used. Someone who's seeking anonymity can't really share anything with you that would distinguish them from spammers. The only thing will be whether they spam, or not.
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?
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).
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?
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.
Sounds like email in general is not the transmission medium you want then.
I think we're at a point where any long messages sent via the internet are going to be called "email" regardless of the actual transmission process. Especially if they aren't meant to be some kind of real-time chat system, as that is usually called "instant messaging".
> Tutanota is the end-to-end encrypted mail client that enables you to communicate securely with anyone.
Secondly: no. Twitter dm's are unlimited in length, and no one calls it email. Web based conversational systems offer long form messages, and people don't call them email.
Email is email, other things are other things. Something can be "email like" and not be email, and if explained that way even the most novice of users can understand that there is a difference, even if they themselves don't specifically understand what the difference is.
Also, please don't use all caps for emphasis. That's in the site guidelines: https://news.ycombinator.com/newsguidelines.html
The "yet another" is simply because the major points the authors themselves claim, are exactly the same as previous things (also submitted to HN) and with exactly the same fundamental problem, which I specifically described, and even suggested an alternative approach to.
I understand that you want to encourage positive feedback, but I have to ask: are you saying my wording needs improvement (i.e. I should have said "this has the same problem as other similar projects, X, y, z") or are you saying negative feedback in general is discouraged?
The most important place to be careful about this is in discussing new work. That of course doesn't mean that all new work is good, but the bias toward tearing things down is so strong (especially on the internet) that it's better to err on the other side.
Are there security considerations between each solution that they took into account when deciding?
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.
Tutanota has implemented their own variation of encryption which is not OpenPGP compliant. Their justification for this deviation rests on their desire to be able to encrypt all aspects of communications (metadata, subject, etc) while PGP doesn't not offer this.