I've recently been looking at ProtonMail, an email service which provides transparent end to end encryption between users with PGP. In order for the encryption to be transparent, ProtonMail manages all of the public and private keys.

When sending an email from a ProtonMail account to another ProtonMail account, the ProtonMail server sends the destination's public key to the client. The client then encrypts the email using the given public key and sends the mail to the server to forward to the recipient, who can decrypt it with their private key.

Since ProtonMail's server only ever sees the encrypted email, and it doesn't have access to any cleartext private keys, it cannot read the email. According to ProtonMail, this means we don't need to trust the ProtonMail server to know it doesn't read the email (assuming it doesn't send malicious javascript with the client).

However, what, if anything, prevents ProtonMail's server from conducting a man in the middle attack by sending the wrong public key? If the server sends the public key corresponding to a private key they control, they could decrypt the email, then re-encrypt it with the correct public key, and send it to the intended recipient. In normal PGP the user must explicitly mark each public key as trusted, but no explicit trust is requested from the user of the ProtonMail client. So how does the ProtonMail client know to trust the public key sent by the server?

  • 1
    $\begingroup$ There is a Reddit question : Can ProtonMail do a man-in-the-middle attack? that answered by the ProtonMail Team 3 years ago. $\endgroup$
    – kelalaka
    Commented Apr 27, 2020 at 22:34
  • $\begingroup$ @kelalaka That's interesting, it seems like they planned to add an opt in for manual key trusting. I'll have to look in to that. But I wonder if there's more up to date info, considering some of the plans mentioned in that post seemed to never have never come to fruition, e.x. a desktop client. $\endgroup$
    – Vaelus
    Commented Apr 27, 2020 at 23:23
  • 2
    $\begingroup$ @kelalaka There is in fact a setting to opt in to manually trusting keys. That setting links to a documentation page which answers my question. I'll write it up as an answer. $\endgroup$
    – Vaelus
    Commented Apr 27, 2020 at 23:44
  • $\begingroup$ @kelalaka: The text that your refer does not actually answer the question. They don't explain how it works. $\endgroup$
    – mentallurg
    Commented Apr 28, 2020 at 3:22

1 Answer 1


ProtonMail has a support page about this topic.

ProtonMail does not transparently solve this problem. By default, the client has no way to know if the server has provided the correct public key, it just implicitly trust keys sent by the server. Therefore, by default the client has no way to protect against man in the middle attacks from the ProtonMail server.

However There is an option to turn on manual trusting of keys, "Settings > Security > Address Verification (optional) > Prompt to trust keys". In this case, when encountering an unknown public key, the ProtonMail client will notify the user that the key is not trusted, and prompt them to "pin" the key. Keys must be pinned, per contact. Messages to contacts without pinned keys will be sent using keys from the ProtonMail server.

A pinned key is stored locally the client, and (presumably) encrypted and sent to the server, so it can be used from other devices when decrypted with the user's password. The client will always use the pinned key to encrypt messages for the corresponding address, and it will display an error if a message received from that address isn't signed with the correct key. It up to the user to verify that the key is correct, like in normal PGP.

  • $\begingroup$ This doesn't prevent ProtonMail server from reading your emails. $\endgroup$
    – mentallurg
    Commented Apr 28, 2020 at 3:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.