Manual key verification

[llebout]

The client does not expose key verification to the user, all users of Tutanota must trust Tutanota to not provide forged keys and perform an MITM attack, this defeats the whole security model of Tutanota, rendering end to end encryption useless. To solve this problem, you must ensure users keep a local copy of a verified keys database, and make sure users do maintain that database and verify their public keys through a side channel such as a physical meeting or several other platforms. The current Tutanota solution does not provide any superior security to Gmail as you still trust Tutanota to not spy on their users by performing an MITM attack.

[charlag]

Hey We understand your concerns and we will discuss different options of improving this after the beta

[llebout]

Note that I don't really appreciate minimization of the issue; this is a core part of any kind of system that performs authenticated encryption, just like SSL would not mean anything without Certificate Authorities. It's not only improvement, I have to disagree on the label. It's a core issue that should have been part of the design from the beginning.

The Tutanota servers currently have the ability to MITM anyone using the service without any way for the user to know about it (the UI does not expose anything about what keys are!), which is the same thing as trusting Gmail for NOT reading your emails, you are trusting Tutanota for NOT doing MITM and then reading the emails, and as there's no way for users to actually detect such an MITM attack, it's practically the exact same thing.

The big problem here, is that your user base is now used to feel safe with the current user interface, when they are not; and changing the usage flow of your application now, is going to make people confused, and affect terribly the actual safety of users.

[charlag]

Well, issues are not for "your service is not good and should have been different from the very beginning", it's small, actionable things for us. I'm sorry that I misunderstood your proposal. If you have another one, we could open another issue. What we could do is open the first letter with another person we could store their key in contacts and warn user if the key was changed. It is also somehow similar to how Autocrypt is designed. Because contacts are encrypted it should be as good as local database. We have no plans to make users maintain a local database of verified keys. I know no person who does this and I know no one who would. If you want this, you better use some other solution but it scares off almost all non-tech (and even some tech-savvy) people.

[llebout]

It is unfortunate that it was not done from the beginning and shows lack of understanding or laxity, but you can still change it now while in Beta. It may scare some users however, it is the ONLY way to do end to end encrypted messaging, else it's not end to end; and thus you are falsely advertising it as end-to-end. There's a lot of people that do this with GPG trustdb, and it is standard. I would save contacts with key/trust information in localStorage and automatically verify those have not been tampered with. Add a button to trust a key, and to save this localStorage copy offline for comparing later if the browser storage is emptied. You can have QR codes similar to Signal for verification of keys on mobile through the device's camera, and same thing for the browser. And an ecoji (https://github.com/keith-turner/Ecoji) encoded representation in the case of non-functional camera.

There's still the issue with mixing webapps and cryptography, Tutanota's servers could start shipping a different version of the webapp with a backdoor and undermine security measures in place, I am awaiting for the web standard to include a system to trust some version of a webapp and in the case it changes, you get a notice, and you must approve/deny that.

[charlag]

Option with local store is no different from adding it to the account, encrypting and putting it to the server (so we still cannot read or change it) or do I miss something? Otherwise on each new login (let's say you don't save session) you would have to go and verify all your contacts. We will not change it while it's in beta because development will not stop after beta. We will get one of these in time. If you don't want to rely on us with shipping the correct web app, by all means, build it on your own, host web client on your own. That's one of the reasons we will ship desktop app soon. There is some magical untrust around shipping code in the browser compared to all other forms of apps which can be compromised in a similar fashion. I'm not sure why you're mixing it up here.

[llebout]

Hi charlag, Encrypting user data does not provide authentication of that data. You can't technically provide end to end encryption if the users don't keep the session, you must introduce a local store. To me, it's wrong all-together to try and establish trust in cryptographic systems while running on the web, people don't realize that, and you offering a way to access it through the web and not solely through the desktop app misleads users. I suggest that prioritization of this issue is raised, this is a core concern of any system that claims to use end to end encryption, you failing to provide authentication for "convenience" puts all users at risk, and you seem to under-estimate gravity of the problem. Don't claim to provide end to end encryption if you are convinced that it's too heavy on the users, it's a lie for questionable goals. I'd like to disagree on that, if you give users the good tools to adopt end to end encryption and stop despising them, they for sure can start using it securely. Thank you and make the good choices.

[realpixelcode]

I know no person who does this and I know no one who would.

I know of no other E2EE communication tool where you can't check the authenticity of your contacts. We're not talking about forcing anyone to verify their contacts. Tuta can still choose to hide that option behind a "more details" button. But not offering such a basic option at all that is so vital for E2EE is very detrimental and perhaps even almost as bad as ignoring Kerckhoffs's principle.

it scares off almost all non-tech (and even some tech-savvy) people.

That has not happened to WhatsApp, Signal, Threema and even Telegram, who all allow their users to manually check the cryptographic fingerprints of their contacts.

[SkypLabs]

This issue has been opened for more than 6 years now, with no clear roadmap or even real consideration from the Tuta team. I have to say, I am disappointed.

You keep saying that "[...] Tuta [is] the most secure email service on the market.", but without key verification, a malicious Tuta server can read the end-to-end encrypted emails and shared calendars exchanged on the platform as there is no way to verify the recipients' public key. As explained by @llebout, "all users of Tutanota must trust Tutanota to not provide forged keys and perform an MITM attack". This is a significant flaw in the technical design of the platform, and it does not seem to bother you.

In #198, it can be read that:

We are aware of the issues with verification, new protocol will support verification, the work is underway

However, your post-quantum implementation has now landed but still no word on the key verification issue.

Could you please stand by what you have said from day 1, that you prioritise security and privacy, and establish a clear roadmap of the work already undertaken or to be done to fix the situation?

Thank you

[bedhub]

Thanks for your comment. I agree that key verification is important and we have it on our roadmap. We are working on it already and we want to implement it in a way that works nicely together with key rotation. We enabled post-quantum encryption for new customers by the beginning of the year, now we are in the process of upgrading existing customers and then we will deploy key verification. We already mentioned key verification when releasing post quantum encryption https://tuta.com/blog/post-quantum-cryptography.