I've emailed them to ask that they fix this. I also created a post on their user voice thing about it.
https://protonmail.uservoice.com/forums/284483-proton-mail/s...
TLDR; Proton Mail tells users to do this:
gpg --armor --export-secret-keys "${USER_ID}" | import-into-proton-mail
gpg --armor --export-secret-subkeys "${PROTON_ENCR_SUBKEY_ID}!" | import-into-proton-mail
gpg --armor --export-secret-subkeys "${PROTON_SIGN_SUBKEY_ID}!" | import-into-proton-mail
1. We don't generate OpenPGP keys on the server, we generate them in the client, and then encrypt them with a key derived from your password (which we never send to the server), and store the encrypted key on the server. Then, when you login again, we fetch and decrypt the private key, and use it in the client. The server never has access to your private keys.
2. We do support "GNU Dummy" keys now (which is what `gpg --export-secret-subkeys` creates). The required private key material needs to be in a single OpenPGP key though (with a dummy primary key), but that's what `gpg --export-secret-subkeys` does by default. Though, as mentioned above, we don't have access to the primary key on our servers either way.
2a. Note that "GNU Dummy" keys are a gpg-specific extension to OpenPGP [1]. The upcoming new version of the OpenPGP standard [2] allows a more standardized way of doing this by combining public key packets and private key packets in a single transferable private key, but it's not widely implemented yet.
3. I would argue that the private key material of the subkeys (used to encrypt and sign your emails) is actually much more important in this case (but of course we don't have access to that either). That's the reason we don't explicitly recommend this: it doesn't meaningfully improve security. But we don't stop you from doing it (now that we support it, even though it's a nonstandard feature), either.
[1]: https://github.com/gpg/gnupg/blob/master/doc/DETAILS#gnu-ext...
[2]: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-cry...
I see, I stand corrected then. Thanks for clarifying. The Proton Mail interface contains buttons labeled "generate" so I got the impression it was being generated in the server. Is this password-derived key the "account key" which I see in the Proton Mail settings interface?
Please clarify what key derivation function is being used. The OpenPGP S2K which gpg uses is outdated and probably not secure enough. I know that Proton Mail is involved in the OpenPGP standards body in an effort to modernize it and that the new RFC contains support for the memory hard argon2 algorithm. Is that what's being used? If so then I would believe that it's even more secure than the encryption that gpg applies to the exported key output.
Are there instructions for verifying that all this is happening? I think a lot of folks on HN won't be convinced otherwise.
> We do support "GNU Dummy" keys now (which is what `gpg --export-secret-subkeys` creates).
Wow that is GREAT and the exact information I wanted! I only believed otherwise because of the documented instructions, which contain the command I posted above. I double checked with Proton Mail support as well but everything led to believe that this was not supported when in fact it was.
Please add this fact to your documentation and instruct your support staff about this!!
> I would argue that the private key material of the subkeys (used to encrypt and sign your emails) is actually much more important in this case (but of course we don't have access to that either).
I agree. Those are the keys which sign and encrypt the data after all.
It's just that I'm going to create an OpenPGP identity for things like signing code commits on git, signing packages I publish. I'm putting quite a bit of effort into getting it right. I printed out the master key to paper in paperkey and QR code format. I even contributed code to ZBar to add binary decoding support so that the key backup is easy to restore. I'll also be making an effort to join the decentralized web of trust.
So I was really hoping to be able to use Proton Mail with this identity instead of the key pair that's generated for the account. This way the emails I send can be signed by the same identity that I'll publish on the OpenPGP key servers. Looks like it's going to be possible after all.
Thanks for reaching out here on HN. I've been a really happy Proton Mail customer and now I'm even happier.
No, the account key is an OpenPGP key which is encrypted with a key derived from your password. The "key encryption key" is not separately visible. The address keys are in turn encrypted using the account key. (The account keys are also used to encrypt your contacts, for example, which are shared between all your addresses - while the address keys are specific to an email address and are used to encrypt emails etc.)
> Please clarify what key derivation function is being used.
We use bcrypt, in addition to the OpenPGP S2K (i.e. the bcrypt output is fed as the "password" to OpenPGP's key encryption).
We are in the process of rolling out updates to OpenPGP.js and GopenPGP which support Argon2 for the OpenPGP S2K step, after which we'll start using that - but we aren't quite yet.
> Are there instructions for verifying that all this is happening? I think a lot of folks on HN won't be convinced otherwise.
Take a look at https://github.com/ProtonMail/WebClients/blob/main/packages/..., for example. Though to be honest, if you want to verify that we aren't sending the password to the server anywhere, in principle you'd have to check the code of the entire web app (or whichever app you're using). It's all open source, but it's a lot of work, of course. But you can also check the latest audit report: https://proton.me/blog/security-audit. They also verified all of this stuff.
> It's just that I'm going to create an OpenPGP identity for things like signing code commits on git, signing packages I publish. (...) So I was really hoping to be able to use Proton Mail with this identity instead of the key pair that's generated for the account.
Yeah, I understand. Though the typical advice from a cryptographer's perspective would be, it's better to use separate keys for separate purposes; and the simplest way to do that is to generate separate OpenPGP certificates, so that's what we'd generally recommend. But, if you want to generate separate subkeys and sign them all using a common primary key, that's also reasonable enough. And, we can improve the documentation on that, although it's a bit of a niche use case (not for HN of course, but for the general audience it is).
> Thanks for reaching out here on HN. I've been a really happy Proton Mail customer and now I'm even happier.
Thanks, glad to hear! :)
that they demanded the private key tells you _everything_ you need to know about protonmail.
The only way to retain full control over all the keys is to do it the hard way: manually encrypt the emails and send that payload via SMTP. If we refuse to give them the keys, we can't enjoy the convenience of Proton Mail doing that automatically for us. Proton Mail offers a middle ground and it's a very attractive one if you accept the inherent risks associated with giving them the keys.
I'm not willing to give them the master key though. I want the ability to generate a bunch of subkeys just for them. Then I can just revoke those keys if they're ever compromised, and the emails will be encrypted and signed by my actual OpenPGP identity that I'm investing time into, not a separate master key generated for my Proton Mail account.
The support guys confirmed to me in writing via email that Proton Mail only ever uses the signing and encryption subkeys. They don't need the master key.
> We use the signing subkey for signing and the encryption subkey for encryption, and you will have to import the whole OpenPGP at once.
So I asked them directly to add support for importing just the subkeys.
I made a post on their user voice thing about this too. It's garnered a bit of support already.
https://protonmail.uservoice.com/forums/284483-proton-mail/s...
Let's see what happens.
Here's my last message to Proton Mail support, request ID 822331. I was directly told no resources would be spent on fixing it:
> Well, it has been multiple years now so can you guys maybe prioritize this? How long do you want me to continue waiting on this issue? I can't count on PM users to send my mailserver E2EE mail when the mobile app doesn't support it.
I would assume that any technically sophisticated users who just want an SMTP/IMAP server would never let their keys leave their control, but there might be other users for whom a "middle layer" service which has their keys is good enough. (I guess this is especially evident in cryptoassets where people seem to cheerfully let third parties manage their tokens, so it's not really surprising to me that there are a bunch of people willing to do it with their PGP keys for email purposes.)
I guess there's an argument about whether or not they're being responsible in providing such an option at all, which is fair enough.
Does that create trust issues? Absolutely. Still, OpenPGP sucks and I just can't fault them for trying to fix it. They're even participating in the standards bodies alongside other OpenPGP projects trying to modernize the whole thing. Somehow it resulted in gpg forking the standard and making everything even worse. It was hard to use before, now it's hard and fragmented.
https://lwn.net/Articles/953797/
https://news.ycombinator.com/item?id=38554393
I suppose they could have gpg or OpenPGP smartcard integration in the bridge, then it could use those keys to sign and encrypt. That's more secure but creates quite a bit of hassle. Suddenly the web and mobile apps become incapable of sending OpenPGP email unless you have the smartcard connected. I've got two NFC enabled YubiKeys and I can't even begin to imagine how to connect this stuff to a smartphone. Looks like there isn't enough support for it.