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.
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.
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.
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.
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.
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....
Good point, I just picked the simplest example. In fact I use Proton for my personal email and wouldn't dream of it if I didn't think your crypto was up to scratch.
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.
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.
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.
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.
that they demanded the private key tells you _everything_ you need to know about protonmail.