Autocrypt support

[BuZZ-dEE]

Hi there, is Tutanota planning to follow the path of other mail clients and implement Autocrypt? Seems like most major clients are planning on releasing support for it soon (K9, Thunderbird, Mailpile). Would be nice if Tutanota follows and stays compatible.

[BuZZ-dEE]

Posteo.de: New: Easy email encryption with Autocrypt and OpenPGP header

[charlag]

I've seen this before, but I don't remember if they just allow this headers and you have to use client which supports it or they do this in web too?

[4jNsY6fCVqZv]

I have a technical question about Autocrypt Support here. What is the point of this feature, if Tutanota messages are already encrypted end to end by default? Isn't that more of a concept to secure unencrypted email providers & emails? Seems to be related to #527 as well.

[charlag]

@4jNsY6fCVqZv this is for encryption to other email providers

[4jNsY6fCVqZv]

@charlag I don't quite understand what this is for. Tutanota to Tutanota is encrypted by default end to end. And for an email exchange with other providers, you have the solution with the extra web interface and the shared password, which also allows an end-to-end encryption, right?

[Silmathoron]

@4jNsY6fCVqZv yeah but that's really more like duct tape rather than a real encryption feature, it's nowhere close to efficient or user friendly... (though it's better than nothing and therefore good to have in the meantime)

[ghost]

Yet another reason for implementing this feature - compatibility with Delta Chat, which is a very popular privacy-focused IM. https://delta.chat/en/help#is-delta-chat-compatible-with-protonmail--tutanota--criptext

[4jNsY6fCVqZv]

@charlag Why do you want to go for Autocrypt at all, which to my knowledge neither has a trust model nor allows one via protocol?

[JimmyCushnie]

It's not about relying on Autocrypt, it's about supporting it. Communicating via autocrypt is better than communicating unencrypted, and sometimes those are your only two options.

[4jNsY6fCVqZv]

From a technical point of view, I have some concerns as to whether it makes sense to support a solution that users want and should trust, but which may not be able to fully meet this requirement from a technical point of view.

Also I am critical if only Autocrypt is supported, but this does not seem to be planned for p=p so far. Both standards are not compatible to my knowledge. However, both pursue a very similar intention: To make encryption finally usable for many many people out there. Tutanota users could then expect end-to-end encrypted messages from only some of their contacts. Although other contacts might be safely reachable via the p=p standard.

Maybe you developers can balance this by supporting both standards out of the box?

EDIT Oh, looks like there's already an issue for p=p integration. https://github.com/tutao/tutanota/issues/812

[fosres]

Hello Tutanota,

You have admitted in a Reddit Post that we are free to start working on the implementation of Autocrypt.

(https://www.reddit.com/r/tutanota/comments/g1jvko/will_tutanota_use_openpgpjs_in_their_forthcoming/)

What directories in Tutanota's source code does Tutanota recommend contributors to review and edit as they attempt to contribute to Autocrypt?

[vitoreiji]

Hi @fosres,

Thanks for offering to help. We had a discussion about this and we decided that it doesn't really make sense to start working on Autocrypt support before our post-quantum mail changes roll out, since this will change the way we handle encryption a lot!

So sorry for misleading you on reddit and thanks again :-)

[fosres]

Ok, thanks for letting me know. Let me know when Tutanota is ready to start developing it.

I will try to work on issue #590 in the meantime. I will comment my questions on development there.

[marceloomens]

Do Autocrypt-exchanged keys signal the type of encryption they were generated for? It is my understanding that Autocrypt was developed with wide adoption of PGP in mind, and that Tutanota does not use the same kind of cryptography as PGP based email exchange.

Is Tutanota's cryptographic model in principle compatible with PGP-based email encryption?

[eternaltyro]

@vitoreiji can you point me to a link or resource to what post-quantum mail changes you are working on? Is there a github issue I can follow?

[vitoreiji]

@eternaltyro There is no issue at the moment, but there will be an update on our blog in the near future, so stay tuned :)

[ghost]

After Implementation, Please consider making a Blog PGP about PGP and Autocrypt in Tutanota and How to use it too. If Possible Video in YouTube Channel would also be great.

[Washee]

I am wondering, why this has been removed from the roadmap. Do you still consider this feature and PGP support in general, like stated here? Or is it dead and you discarded this idea to enable people using external mail services in combination with pgp from communicating e2ee with tutanota-users?

[charlag]

@Washee it is unclear yet when and if it will be implemented. Autocrypt doesn't give you PGP support and there are basically no services that do Autocrypt at the moment. We will first concentrate on our new post-quantum encryption protocol first and then consider whether or how we could support other formats.

[BuZZ-dEE]

https://github.com/ProtonMail/WebClients/issues/120

ProtonMail Autocrypt

ProtonMail : Support autocrypt for messaging with non-protonmail addresses

ProtonMail: Incorporate Autocrypt into the Protomail Apps.

[BuZZ-dEE]

and there are basically no services that do Autocrypt at the moment.

Why do you need a service? There are clients out there that support Autocrypt.

https://autocrypt.org/dev-status.html

I think your service is for now a walled garden. Are you interesting to change that?

[charlag]

Let me put it more clearly: Autocrypt has almost no use in the wild at the moment nor do we have capacity to implement it. It also has a lot of security drawbacks inherited from PGP.

We do not want to be a walled garden. Once our PQ-encryption is in place we can consider how to best interop with others keeping benefits of perfect secrecy and post-quantum encryption.

[BuZZ-dEE]

We do not want to be a walled garden.

I don't believe that. This ticket is over 4 years old. We need an open standard.

If Autocrypt does not fit your needs. You have other possibilities. For example:

• https://github.com/tutao/tutanota/issues/812
• Call ProtonMail and make Tutanota compatible to ProtonMail
• Call Ctemplar and make Tutanota compatible to Ctemplar

It also has a lot of security drawbacks inherited from PGP.

Better than no encryption.

Once our PQ-encryption is in place we can consider how to best interop with others keeping benefits of perfect secrecy and post-quantum encryption.

When will it be finished?

[mmahmoudian]

I tried to read all the arguments in different threads on this repo and also some blog posts. But as a long-time paid customer, one thing is very annoying here:

It has been mentioned twice [1, 2] in this thread and numerous times else where that post-quantum encryption is being considered and worked on in Tutanota, and "there will be an update on our blog in the near future" but no ETA was ever given. Over one year ago @BuZZ-dEE asked "When will it be finished?" and we are yet to receive a reply.

This "post-quantum secure encryption" has been very briefly touched upon in a blog post but it lacks any technical detail nor any ETA. This is in spite of the following part in that blog post:

By now, we have a running prototype that can encrypt emails with standard encryption algorithms as well as post-quantum secure algorithms in a hybrid protocol, the most innovate encryption to date.

So, if there is a working prototype, as reported in 2023-02-09, can we at least get an ETA?

I would like to second on some of the remarks @BuZZ-dEE made:

This ticket is over 4 years old. We need an open standard.

Now it is 5.5 years old. Additionally, because we do not have IMAP/SMTP, nor being able to upload a PGP private key to Tutanota (I don't like it, but at least it is an "improvement" to the current state), there is no way to communicate safely and securely with anyone that is outside of Tutanota. This is the definition of walled-garden like it or not (further reading material).

[PGP is] Better than no encryption.

At this point, virtually anything (including but not limited to sneakernet, or even Internet Protocol RFC 1149) is more secure than using Tutanota to send message to someone that is not on Tutanota. This is not to mock anyone here, but to clarify that at the moment sending email to non-tutanota accounts means sending plain-text (and no, password stuff of tutanota is not good, no one in my circles opened it as it is very unorthodox and looks like scam to people. I had to send the email again but in plain text, or call them!!).

[BuZZ-dEE]

The whole quantum encryption is useless if you only can send encrypted mails to other Tutanota users, especially if Tutanota is forced to provide a backdoor. https://www.heise.de/news/Gericht-zwingt-Mailprovider-Tutanota-zu-Ueberwachungsfunktion-4972460.html

[snan]

PGP is already more secure than RSA-2048 🤷🏻‍♀️ And that's not saying much since PGP does have some issues, but it'd be a step up from what Tuta uses now. And PGP is actively working on post quantum.

WKD is a competing standard to Autocrypt that doesn't have the same MitM issues and Proton uses WKD today. In other words, Tuta could implement WKD and be seamlessly, zero-click compatible with Proton's e2ee without having to call or negotiate with them.

I've never used Proton in my entire life but since I have WKD on my home made email, Proton users automatically encrypt when they send to me. They don't need to do anything or even understand what's going on, it's just automatically encrypted.

Autocrypt does have some advantages: • It can be implemented clientside so it can work for Gmail and Hotmail users if they use apps like Mailvelope or Delta Chat. • That also means volunteers can start implementing it in this repo, unlike WKD which would have to be implemented serverside at Tuta. (The encryption isn't server side, just the pubkey exchange.)

[realpixelcode]

Tutanota is forced to provide a backdoor. https://www.heise.de/news/Gericht-zwingt-Mailprovider-Tutanota-zu-Ueberwachungsfunktion-4972460.html

If you had actually read the article, you would have noticed that

the monitoring measure only affects new incoming unencrypted emails. The company cannot decrypt data that has already been encrypted or end-to-end encrypted emails in Tutanota.

That is not a "backdoor".

for an email exchange with other providers, you have the solution with the extra web interface and the shared password

Yes, as a Tuta user you can send a symmetrically encrypted e-mail to an external recipient. However, external recipients cannot send you encrypted e-mails unless they are replying to a mail from you. That means there is currently no easy way to initiate an end-to-end-encrypted conversation with a Tuta user if you're not a Tuta user yourself.

You could, in fact, generate a PGP keypair for your Tuta address via GPG on your local machine, but in order to actually read incoming PGP e-mails you'd either have to

• tell external senders to use inline PGP (instead of PGP/MIME) so that you can use the Mailvelope browser addon as a hacky work-around or
• export the e-mail as an .eml file and open that in an e-mail client like Thunderbird.

Neither of these options is very user-friendly for Tuta users, and I doubt that the average non-technical person would even know how to do that.

We do not want to be a walled garden.

That's good to hear! An idea from me: Instead of going full PGP support overnight, you could do little steps and, for example, start by displaying PGP signatures (or maybe even S/MIME signatures!) from external contacts. It's very important for Tuta users to be able to verify that e-mails they receive are legit, especially if they come from external services that haven't been designed to be as secure as Tuta. So, when an external sender has made it easy to verify the authenticity of an e-mail (and thereby has basically already done a great portion of the job for you), Tuta should IMHO make use of that opportunity.

PGP is already more secure than RSA-2048

Yes, it can be. But insecurely short PGP keys are still being used, and frequently users don't understand that some of their PGP conversations might not be as secure as they presume. Moreover, quantum computing is a risk to all public key cryptosystems in general, not just PGP in particular; and it is not entirely clear whether they can be secured against quantum-computing attacks at all.

Better than no encryption.

That's the point! Being a Tuta user currently means for each of my contacts: Either they're also a Tuta user, or our conversations are completely unencrypted. Like, without any protection whatsoever. That's much, much worse than just falling back to Autocrypt/PGP.

It's not about relying on Autocrypt, it's about supporting it.

100%! Also, Tuta could

• still set their symmetric encryption as the default when drafting a new mail
• when replying to PGP-encrypted e-mails, prominently display that PGP is not as secure as Tuta's encryption, for the various reasons already brought forth.

[snan]

But insecurely short PGP keys are still being used, and frequently users don't understand that some of their PGP conversations might not be as secure as they presume.

Thankfully, the key algo and length they're using is completely visible so alerting a user that they're about to send an email to a friend who is on RSA-2048 or worse is just a smop away 🤷🏻‍♀️

Here are the people I've been emailing with:

gpg --list-keys |grep ^pub|cut -c7-13|sort -u   

Pretty good!

[snan]

still set their symmetric encryption as the default when drafting a new mail

Tutanota uses asymmetric encryption between Tuta users. RSA-2048, just like older PGP versions used.

prominently display that PGP is not as secure as Tuta's encryption, for the various reasons already brought forth.

That would be a lie. 😰

[realpixelcode]

Tutanota uses asymmetric encryption between Tuta users.

Whoa, seems like I never noticed that AES-256 is only used for external recipients. 😳 (In retrospect, that assumption seems kinda stupid.)

[SkypLabs]

It's very important for Tuta users to be able to verify that e-mails they receive are legit, especially if they come from external services that haven't been designed to be as secure as Tuta

The problem is also present for e-mails from other Tuta users. We, as Tuta users, have no easy way to verify that our e-mails are end-to-end encrypted with our recipients' key (and vice versa). As a result, a malicious server can easily provide keys which are not the ones of the legitimate recipients but ones controlled by a third-party actor who will be able to decrypt all e-mails. This design issue has been reported by @llebout 5 years ago: https://github.com/tutao/tutanota/issues/768

[charlag]

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

[0xC4aE1e5]

Now that TutaCrypt is done, why not add this back into the roadmap?

[snan]

Right, autocrypt also uses x25519.

[solid-snail]

Sorry to bump an old request, but it is becoming a deal breaker feature for me.

My use case is submissions to Zero Day Initiative. They require email communication to be openpgp encrypted, and failing to do so disqualifies the submission. Losing a month's worth of work because you accidentally attached the unencrypted file is a tough bullet to bite.

I'm not exactly in a position to convince them to use tuta, so openpgp is required for me. It can be an extra paid business feature. There's obviously a business use case for it.