[matheusmoreira]

Some interesting facts about Proton Mail. It generates OpenPGP keys on their own servers, and if you want to use your own keys their instructions show users how to upload upload their entire OpenPGP secret keychain to Proton Mail. Not just encryption/signing subkeys, the master key also needs to be included.

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

They should support this instead:

  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

First one leaks the user's master key to them.

[twiss]

Hi! Crypto team lead here.

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

[matheusmoreira]

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

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.

[twiss]

> Is this password-derived key the "account key" which I see in the Proton Mail settings interface?

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! :)

[matheusmoreira]

Thanks for clarifying.

> although it's a bit of a niche use case (not for HN of course, but for the general audience it is)

No doubt about that. Safe to assume that 99% of your users will not know or care about this. That's why I want to thank you for supporting this advanced key management feature for those of us who want it. To me that's evidence that Proton Mail takes OpenPGP seriously.

[underlogic]

fix it? are you kidding!

that they demanded the private key tells you _everything_ you need to know about protonmail.

[matheusmoreira]

Well, they are literally in the business of making OpenPGP easy to use. I understand your worry but I can also understand where they're coming from. The fact is PGP is stupidly hard. I once ran into a gpg bug that deleted my master key. I got so frustrated I just gave up and forgot about it for years. Without services like Proton Mail, this stuff is just never going to be mainstream.

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.

[guappa]

They could have kept the private key in the browser instead of in the server and let the user get the file there.

[matheusmoreira]

They could but then you open the mobile app or another computer and the key just isn't there. They could generate one subkey for each device but then you risk user emails being impossible to decrypt if they ever lose that device. Hell I'm a programmer and I somehow managed to get my own master key deleted because I ran smack into some gpg bug which I then reported and sent a patch for. If I can't do this without deleting my keys and being forced to revoke them from keyservers immediately after publishing, what hope do end users have?

The most secure solution is to generate keys on an OpenPGP smartcard like an NFC enabled YubiKey and use that key everywhere. Even that's incompatible with maximum reliability: YubiKeys can and will eventually fail and when they do your keys are gone. So you can't generate the encryption subkey on the smartcard, you need to generate it on a secure device, back it up to paper just like the master key, and then copy it to the smartcard. Otherwise you risk being unable to decrypt data later.

It's an incredibly hard problem and it's full of tradeoffs. I can at least respect their attempt to solve the problem.

[Y_Y]

So can you put in a dummy master key after the export and before the upload?

[matheusmoreira]

Maybe. I haven't tried it. Someone actually suggested this to me on the #gnupg IRC but I just kinda forgot about it.

The --export-secret-subkeys command does just that: it replaces the master key with some GNU specific stub packet thing. It's conceivable that they could detect this and reject the uploaded key. In order to avoid that, one might edit the secret key packet manually instead. Just zero fill or randomize all the secret key bits or something. I assume it wouldn't match up with the public key though. Aren't the public and private keys mathematically related? Maybe you can detect that the key is bogus if you try to do cryptographic operations with it. Maybe the operation somehow fails or produces nonsense results. I don't really know enough cryptography to say.

[twiss]

Indeed filling the private key with zeros or random data wouldn't work, but we do support GNU Dummy keys as exported by `gpg --export-secret-subkeys` nowadays.

[Y_Y]

RFC4880 uses ElGamal for the asymmetric encryption and so it's a discrete log problem. Roughly the private key x should satisfy `a=b^x mod n` where b and n are known, and a is part of the public key. It goes through similarly for elliptic curve-based schemes.

[twiss]

FWIW, OpenPGP doesn't only offer ElGamal, and we never use that algorithm. We use Curve25519 by default since quite a while, before which we used RSA. We've never used ElGamal and also don't allow importing ElGamal keys, since they're insecure and deprecated in the crypto refresh (the upcoming update to the OpenPGP standard): https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-cry....

[underlogic]

It's a "trust me" story. Honeypot

[jorvi]

It is also security theater. 99.9% of the time the other side you are communicating with stores their mails with server-side encryption. If your fancy encrypted e-mails have a "plaintext" mirror, your encryption is useless.

You want to optimize your 99.9% case for convenience (say, use Fastmail), and optimize your 00.1% case for security (manually managed PGP with a secondary anonymous e-mail). It makes no sense to trade away swathes of convenience and security just so you can be lazy with your 00.1% case.

[matheusmoreira]

I view Proton Mail as the convenient 99,9% case. It's a very polished service and it seems to offer a somewhat higher security baseline than the other email providers which probably don't even try to do anything encryption related.

The maximum security manual OpenPGP 0.1% case is still absolutely necessary though. No doubt about that. Anyone claiming that Proton Mail solved this doesn't actually understand how OpenPGP works. Not that I would fault them for failing to understand this ludicrously complicated stuff.

[protonmail]

https://news.ycombinator.com/item?id=40283698

[matheusmoreira]

I can't deny that possibility. Still, it should be an individual's choice to risk it or not.

[BoredPositron]

It is but if I exchange emails with a Protonmail user I am writing with them like there is no encryption present.

[matheusmoreira]

That's probably wise. I wish there was a way to add metadata to the subkeys. I want to have one set of subkeys for Proton Mail and another set for absolute privacy. I want to mark them as "leaked" keys somehow. Not quite revoked but close.

I read the OpenPGP standard and it seems to have some kind of "notation" packets. Seems to be somewhat related to metadata but I can't figure out how it works or even what its purpose is and it looks like nothing ever uses that anyway.

[medo-bear]

Of course you are right, if majority of individuals were informed and if protonmail was proactive in informing their users about short commings. The problem is that most users are not informed and they think that protonmail is the bee's knees of email privacy and security, while protonmail only promotes that myth.

[emptysongglass]

Proton Mail also still doesn't detect WIKD keys on the other side despite reporting it over 5 years ago.

[twiss]

We do fetch keys from WKD, as announced almost 5 years ago: https://proton.me/blog/security-updates-2019 :)

[emptysongglass]

Actually, you have a bug that has been unfixed for 5 years now. I know because I submitted it. Still no action.

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.

[sevagh]

So is the feature missing or is your support ticket open?

[emptysongglass]

It's been open for 5 years.

[ta988]

Of course they will not. If you look at everything they propose there is always that one thing that makes them control everything. Their IMAP bridge, key generation etc

[trog]

I don't know much about Proton Mail but presumably they want that so they can actually provide you with a more complete service, other than just being a mail gateway?

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.

[matheusmoreira]

It's how they make OpenPGP easy to use. Everyone who's ever tried it knows how hopelessly complicated it is. Their bridge's entire purpose is to present a standard email server to email clients so that all the OpenPGP stuff can be done automatically and transparently behind the scenes.

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.

https://news.ycombinator.com/item?id=40177539