You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 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?
@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)
Reacted by André, masvil, Gilberto Ruiz and Pixelcode
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.
Reacted by Silmathoron, Chris Miller, John Wuller, Yogesh, 2fsbb9op, masvil, Gilberto Ruiz, Pixelcode, onsmallfin and A248
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. #812
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 :-)
Reacted by John Wuller, Xing Shi Cai, Yogesh, paulo-roger, XTY, Craig W. Blake and Sebastian Schlatow
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?
Reacted by Gilberto Ruiz, Craig W. Blake, Fazle Rabbi, masvil, Rodrigo Dias, Alex Gorichev, Mehrad Mahmoudian, besendorf, Zitrone, Nguyễn Huỳnh Anh Khoa and 6 more
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!!).
Reacted by John Wuller, Felecarp, Mylloon, Sebastian Schlatow, Fazle Rabbi, besendorf, Zitrone, realshovanshah, Jimmy Boucher, Alireza Rashidi and 3 more
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.)
Reacted by Mehrad Mahmoudian, Sebastian Schlatow, Pixelcode, Zhinn0, Anthony Accioly, Alireza Rashidi and Prince527
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.
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 🤷🏻♀️
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: #768
Reacted by Pixelcode, Bceez, Zhinn0, Alireza Rashidi and A248
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.
Reacted by Pixelcode, Skyper, Felix Kastner, Adam Höllerl, Alireza Rashidi, Jakub Bliźniuk, Maya and A248
Is there any new updates on the status of this? As things are it feels like the community has been strung along for several years now on this issue. If Tuta has no plans to support PGP or similar common standard it would be nice to have that clearly stated rather than left in limbo.
It is commendable that Tuta has put the work they have into quantum resistant crypto and other areas of the service that has seen steady improvement, but in my view not supporting common encryption standards that can be used to exchange messages with other providers with some level of security is a case of letting perfect be the enemy of good.
Reacted by paulo-roger, Adam Höllerl, HEJOK254, Uziel Linares, Pixelcode, vıacoro, Bear-Creator, Adam, Quote, J. C. Müller and 10 more
Activity
BuZZ-dEE commentedon Nov 20, 2018
Posteo.de: New: Easy email encryption with Autocrypt and OpenPGP header
charlag commentedon Nov 21, 2018
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 commentedon Oct 6, 2019
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 commentedon Oct 7, 2019
@4jNsY6fCVqZv this is for encryption to other email providers
4jNsY6fCVqZv commentedon Oct 8, 2019
@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 commentedon Oct 30, 2019
@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)
4jNsY6fCVqZv commentedon Feb 14, 2020
@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 commentedon Feb 14, 2020
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 commentedon Mar 16, 2020
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. #812
fosres commentedon Apr 15, 2020
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 commentedon Apr 16, 2020
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 commentedon Apr 16, 2020
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.
11 remaining items
BuZZ-dEE commentedon Apr 4, 2022
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:
Better than no encryption.
When will it be finished?
mmahmoudian commentedon May 20, 2023
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:
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:
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).
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 commentedon May 20, 2023
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 commentedon Nov 29, 2023
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 commentedon Feb 27, 2024
If you had actually read the article, you would have noticed that
That is not a "backdoor".
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
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.
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.
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.
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.
100%! Also, Tuta could
snan commentedon Feb 27, 2024
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:
Pretty good!
snan commentedon Feb 27, 2024
Tutanota uses asymmetric encryption between Tuta users. RSA-2048, just like older PGP versions used.
That would be a lie. 😰
realpixelcode commentedon Feb 27, 2024
Whoa, seems like I never noticed that AES-256 is only used for external recipients. 😳 (In retrospect, that assumption seems kinda stupid.)
SkypLabs commentedon Feb 28, 2024
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: #768
charlag commentedon Feb 29, 2024
We are aware of the issues with verification, new protocol will support verification, the work is underway
snan commentedon Apr 1, 2024
Right, autocrypt also uses x25519.
solid-snail commentedon May 27, 2024
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.
nehemiagurl commentedon Feb 12, 2025
i see this issue got removed from the roadmap. does this make it a not-planned?
Inconel625 commentedon Mar 3, 2026
Is there any new updates on the status of this? As things are it feels like the community has been strung along for several years now on this issue. If Tuta has no plans to support PGP or similar common standard it would be nice to have that clearly stated rather than left in limbo.
It is commendable that Tuta has put the work they have into quantum resistant crypto and other areas of the service that has seen steady improvement, but in my view not supporting common encryption standards that can be used to exchange messages with other providers with some level of security is a case of letting perfect be the enemy of good.