No, they could just transmit PGP encrypted emails down IMAP and the user could decrypt them with any number of popular PGP implementations. Your IMAP/SMTP password doesn't necessarily have to be the same as your PGP key password, nor should you even need to give Protonmail your PGP private key (password protected or not), nor does IMAP/SMTP even have to be authenticated with a password (GMail notably pioneered an OAuth-based extension to both).
This is completely ignoring key management as a barrier to using encryption, not to mention manually syncing local keystore with the server, not being able to provision keys across devices, etc. In other words, why PGP and email encryption in general has largely been a failure over multiple decades. It's too complex and too difficult.
I think you hit the nail on the head here. Using PGP/GPG has a lot of upfront cost in learning how to create keys, syncing them, getting them signed, storing them securely, etc. To be absolute certain that the private key is not stolen you even need to create them on an air-gapped machine and use a hardware device like a yubikey when using keys on online machines.
I think in the end most computer users will sacrifice a bit of security for convenience. PGP signature and encryption for email will most likely never take off. Encrypted chat services like Signal seems to have done much better, likely because of how convenient they are to use.
You're right about the usability difficulties of syncing local keystores across devices and with the server. Fortunately some good work has been done in this area recently:
This stores the private key as a password-encrypted file in a specified location on the IMAP server. It already has multiple interoperable implementations, by the looks of things.
None of these difficulties prevent you from making the access available. It has no bearing on users who already choose not to use IMAP. This is a pretty bad excuse.
Only if you completely discount the related costs of building and maintaining such an additional API as well as the customer service impact of basically allowing users to screw up their own key management.
Even if I concede this to you (and I don't), you've already written an IMAP/SMTP bridge that solves these problems. Open source it and make it available to free users and the problem disappears (well, is reduced. Most non-technical users don't know how to run a daemon after all, and making them put it on their own infrastructure is lame as hell).
Because running PGP software and handling key management locally is way easier than double-clicking on an installer? I don't concede that for a second. Remember that the alternative you want is ciphertext directly via IMAP, which is not at all user-friendly, which is exactly why we didn't do it.
As for the bridge, that is exactly what we'd like to do, as I've said before.
And customer support time and developer time devoted to this would cost money and represents an opportunity cost as well and that's a fact, not a point to be conceded.
And like I've said before, what you'd like to do and what you are doing are different. Nothing stops you from open sourcing it today. Put in comments that the APIs you use are not officially supported if you must. Open source it! It should have been open source a year ago! Open source it!
Is there a way to encrypt message headers while using IMAP?
My understanding of Protonmail's argument (not that I agree with it) is they encrypt the full message, including headers upon accepting it. Based on my understanding of IMAP, you're effectively looking at a new protocol once you do everything needed to decrypt headers on the client-side.
> Is there a way to encrypt message headers while using IMAP?
Other than the Received, Delivered-To and Return-Path headers added by the intermediate MTA servers, every other header in the original message could be encryped, along with the message body when it's delivered to the server (or appended via IMAP).
Protonmail's method of encryption allows them to encrypt the entire message, including headers/metadata. It also encrypts the messages received that weren't encrypted when they weren't first sent.
Your suggested method basically is no different from any other provider. You rely on the sender encrypting the message and header information is entirely unencrypted on the disk.
>Protonmail's method of encryption allows them to encrypt the entire message, including headers/metadata
I would prefer to see them promote standards to extend PGP rather than invest that time in a new, proprietary system with no buy-in from the email-related-software development community. I can follow the logic but I can also see their eyes lighting up when they realize this is a great excuse for having a proprietary, locked-in platform.
>It also encrypts the messages received that weren't encrypted when they weren't first sent
