OpenPGP messaging between protonmail users and Delta Chat users.
Protonmail is accepting PGP public key from Delta Chat and future mail are encrypted, but Delta Chat is not able to accept the OpenPGP key provided by protonmail to decrypt the message.
I can confirm this behavior.
Hi and a warm welcome 
IMHO the problem is Autocrypt.
Ok, not really Autocrypt 
The problem is, DC uses Autocrypt to
transfer the public key to the receiver. But Protonmail dosn’t support
Autocrypt AFAIK.
Probably the key from the Protonmail will not sent to DC. So DC will not
know the public key of the Protonmailaddress.
I’m not absolutely sure. But I think so.
Thanks webratte! 
yeah, it would be nice if Protonmail (and Tutanota) would start supporting Autocrypt soon!
I hope there is some way to solve this until then…
Hi
My testing:
Understanding standard OpenPGP email would be wonderful.
Haven’t checked lately but i think Protonmail accepts incoming Autocrypt keys but it does not produce outgoing Autocrypt keys so Delta Chat can’t encrypt to it. Hopefully that changes some day but it’s on their side, mostly.
I confirm this behavior.
It would be great to tap on the attached key, to get a pop up “would you like to use this key to communicate with foo@protonmail.com”, click yes/no and to use the key subsequently
Just stumbled upon the same situation after switching my email to protonmail. It’s a bit a disappointing, but I guess we cannot have everything at all yet 
What I do not understand: could this be even solved by Delta Chat alone? (as far as I understand yes, if it would implement full OpenPGP support… but I do not really understand what I am talking about, I just want to able to explain the situation. )
Any links I should read would be appreciated.
For those interested, here is what gathered so far:
In FAQ - Delta Chat i read:
Autocrypt uses a limited subset of OpenPGP functionality.
In OpenPGP Considerations, Part III: Autocrypt and Encryption by Default · OpenKeychain
In K-9 Mail version 5.400, OpenPGP encryption was changed to adhere to the Autocrypt specification.
In “Update on Autocrypt support” on Protonmail reddit by a protonmail staff member (am not allowed more than 2 links, sorry:
Our feeling is that the [autocrypt] protocol has significant security weaknesses and therefore we don’t feel it’s ready for implementation.
Thanks for your input. Do Protonmail refer to any source regarding their feeling?
no: https://www.reddit.com/r/ProtonMail/comments/c1p5am/update_on_autocrypt_support/
I’ll check their blog when I have the time and then maybe ask them directly.
Not entirely related, but Delta Chat has been tested with ProtonMail IMAP/SMTP bridge. The result is unfortunate, ProtonMail bridge corrupts MIME structure of outgoing OpenPGP messages and strips Autocrypt header away:
So even with ProtonMail bridge and Delta Chat client running on your desktop it is currently impossible to have encrypted chat with ProtonMail address and encryption. MIME structure corruption is recoverable, but we need to either fix the bridge to keep Autocrypt header, if it is possible with ProtonMail API, or find a way to exchange keys via attachments.
Hey, any updates on this?
I do get encrypted messages to my DC from PM that I can only read in DC. But I cant find any documentation.
Hello there 
,
For your information, some of us could perhaps keep voting for a feature request available from
It was published about two years before those concerns were voiced around.
Some folks at Proton might will be willing to help us prevent the autocrypt headers from being stripped away if that is one of the underlying issues Delta chat to protonmail user - #11 by link2xt
Delta Chat could let us import Proton’s keys. They use WKD.
There’s another thread for that already and a more specific WKD thread. This would solve interop with Proton users.
What is the goal of using PM with Delta Chat?
PM owns private keys.
Proton stores an AES-256 encrypted version of the user’s private key, so they can’t apply it server side to decrypt or encrypt.
Delta Chat has more opportunities to snarf private keys than the web version of Proton does, if they were to add “phoning home” to the App Store or Google Play releases (although that would hopefully be detected by us users if we lan snooped ourselves).
One opportunity Proton has to steal the key would be through a backdoored version of their bridge. Not everyone uses their bridge, but for those who do, it’s important to use a version of it (either the original or the Hydroxide clone) with a verified compilation process and not trust rando binaries. They would be able to hide home-phoning much easilier than Delta Chat could.
There is also another reason.
My own email is in a Dovecot repo hosted in a Linode VPS (now owned by Akamai), I don’t use Proton.
If I send a PGP encrypted message to a Proton user, and you’re right in saying that Proton have managed to sneak in a back door through several audits and world-readable client side code (not impossible—code obfuscation is a hell of a drug. Never forget Heartbleed), they can read it. But Akamai/Linode can not.
If I send a plaintext message to a Proton user, both Proton and Akamai/Linode can read it. That’s worse.
(Thanks to TLS, eavesdroppers cannot read it.)
you just need some fail in ssl pinning or dns then a ISP or organisation network admin could middle the connection and give out a modified web client that exfiltrates the key. This could be done targeted so would be harder to find, mind that app stores could also do targeted replacement of the DC app build in theory.
I wouldn’t say one or the other is more secure, maybe besides that deltachat does not store the key encrypted and on some systems (desktop) other apps could access and steal it, but so could a compromised browser or malicious browser plugin with proton mail.
But always depends on how badly the bad actors want your data and who your bad actors are that you are scared of.
security does not exist. It’s always about the context: secure against what?
Proton could also start to support autocrypt 
But I’m not really against WKD, sounds like a better solution than key servers provided that you trust your provider
Though as Holger already said in the WKD topic we need a real concept to integrate it seamlessly into deltachat, which is not trivial:
You’d need to fail in both SSL and DNS at the same time, wouldn’t you? And even then the web client’s source is readable (albeit very obfuscated / long). Again, I don’t use Proton myself.
As I’ve asked them many times.
But I’ve come to this philosophy:
Why? Because there are always gonna be projects that are complete jerks like Thunderbird (who “does not support the Autocrypt philosophy that encryption should be fully automatic” 
🪿) or Tuta (who wants to leverage the vendor lock-in of their proprietary network) or projects hesitant to adopt Autocrypt because of the mitm issue* or because they’re invested in the WKD solution.
*: Which DKIM mitigates.
There is such obstinacy around the Autocrypt vs WKD vs all-manual-all-the-time camps. Which I understand, there’s NIH and there’s pride and there’s simply the fact that WKD and Autocrypt both have their cons (WKD requires server-side support which not all providers will implement, Autocrypt requires at least one message sent before encryption can start) The only way out of the impasse is to be the bigger person and break the stalemate by implementing the competing thing too.
We have a chance to significantly up the amount of PGP & e2ee sent in the world but we’re leaving it on the table because of pride.
Even Proton for all their love for WKD can work with manual key imports and exports too, with vanilla PGP. The WKD automatic thing is just a bonus.
Whenever Delta Chat shows me a PGP email from someone who doesn’t have Autocrypt headers, I can’t reply to them. I have to open my other MUA which can handle it. And this is happening several times per day. Delta Chat gets relegated to being a mere xbiff to remind me to SSH into the other MUA.
If the person does have Autocrypt headers, I can respond, and if they don’t encrypt at all, I can respond—in other words, it’s easier to handle someone who doesn’t use encryption! That if nothing else should be a sign that something is wrong here.
And what’s worse, and this happens often, too often, is that I won’t even realize that they’re an encryption user because they don’t have Autocrypt headers. Because if I reply accidentally from Delta Chat, it sends non-encryptedly! And that has happened many times. For each and every sender I need to remember whether this is someone I can safely reply to from Delta Chat or not. That’s not a good feeling. That’s a ball of stress.