Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autocrypt support #198

Open
BuZZ-dEE opened this issue Dec 22, 2017 · 31 comments
Open

Autocrypt support #198

BuZZ-dEE opened this issue Dec 22, 2017 · 31 comments
Labels
idea notes down not immediately solvable things that don't have general buy-in yet new feature user stories in varying refinement states

Comments

@BuZZ-dEE
Copy link

BuZZ-dEE commented Dec 22, 2017

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.

@mpfau mpfau added the new feature user stories in varying refinement states label Jan 3, 2018
@BuZZ-dEE
Copy link
Author

BuZZ-dEE commented Nov 20, 2018

@charlag
Copy link
Contributor

charlag commented 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?

@armhub armhub added this to the Roadmap milestone Dec 11, 2018
@charlag charlag added this to Planned in Roadmap refinement Jan 30, 2019
@4jNsY6fCVqZv
Copy link

4jNsY6fCVqZv commented 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
Copy link
Contributor

charlag commented Oct 7, 2019

@4jNsY6fCVqZv this is for encryption to other email providers

@4jNsY6fCVqZv
Copy link

@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
Copy link

@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
Copy link

ghost commented Feb 8, 2020

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
Copy link

@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
Copy link

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
Copy link

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
Copy link

fosres commented 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
Copy link
Contributor

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
Copy link

fosres commented 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.

@marceloomens
Copy link

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
Copy link

@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
Copy link
Contributor

@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
Copy link

ghost commented Oct 20, 2021

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.

@bedhub bedhub added the idea notes down not immediately solvable things that don't have general buy-in yet label Feb 4, 2022
@bedhub bedhub removed this from the Roadmap milestone Feb 4, 2022
@Washee
Copy link

Washee commented Mar 20, 2022

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
Copy link
Contributor

charlag commented Apr 4, 2022

@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
Copy link
Author

BuZZ-dEE commented Apr 4, 2022

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
Copy link
Contributor

charlag commented Apr 4, 2022

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
Copy link
Author

BuZZ-dEE commented Apr 4, 2022

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:

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
Copy link

mmahmoudian commented 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:

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
Copy link
Author

BuZZ-dEE commented 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
Copy link

snan commented 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
Copy link

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
Copy link

snan commented Feb 27, 2024

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
Copy link

snan commented Feb 27, 2024

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
Copy link

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
Copy link

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 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea notes down not immediately solvable things that don't have general buy-in yet new feature user stories in varying refinement states
Projects
None yet
Development

No branches or pull requests