I dislike that a website with privacy in the name collides privacy and anonymity. Privacy does not protect you from the state. Privacy is good enough to protect you from the public.
If you are doing battle with or an enemy of the state, much less an agent of the state acting in bad faith simple privacy will do nothing for you. Worse your misunderstanding of it is actually a vector, like in this case. The measures for anonymity you require will not incorporate fancy UIs, nice features, or even reasonable reliability at times because they will be sacrificed in the name of leaving no trace.
Privacy is also meant to protect you from the state, or more specifically state abuse. It's an essential aspect of privacy.
Like privacy is also meant to e.g. not disclose topics you have communicated about so that it can't be abused against you. For example there is a long history of states persecuting people for idk. being gay, believing in a certain religion or being a journalist which was involved in a unpleasant disclosure.
Still privacy and anonymity are two tightly related but different things. Mainly privacy of communication doesn't always imply anonymity, through sometimes does (and has too!).
Anyway it is foolish and somewhat strange to believe that a legally operating email service will protect you against judge backed lawful orders (no matter if it should be lawful or not).
Handing out metadata isn't even the worst which can happen, e.g. a judge might order them to make copies of unencrypted mails you receive or make copies of unencrypted mails you write or even undermine your encryption the next time you login.
They can try to dispute it and that alone does reduce abuse potential (if they operate in a place which still can be called a state of law) in the end especially for mail there is just no true privacy and even less anonymity.
Which doesn't mean their service is useless.
Just if you worry about political prosecution by EU countries, or do crime it's not protecting you.
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.
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.
> 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.
> 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.
> 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.
Email marketing is an incredibly powerful tool for businesses looking to enhance their marketing strategies and achieve a high return on investment. One of the primary benefits of email marketing is its cost-effectiveness; compared to traditional marketing channels, email campaigns require minimal financial outlay while reaching a broad audience. Additionally, email marketing allows for highly personalized communication, enabling businesses to segment their audience and tailor messages to specific customer groups. This level of personalization fosters stronger customer relationships and increases engagement rates. Moreover, email marketing provides measurable results, with detailed analytics on open rates, click-through rates, and conversions, allowing businesses to refine their strategies for maximum effectiveness. It's also an excellent way to keep customers informed about new products, services, and promotions, thereby driving sales and increasing brand loyalty. By integrating email marketing into their overall marketing strategy, businesses can maintain regular contact with their customers, build lasting relationships, and achieve sustainable growth. This is a best place to buy gmail accounts - https://www.bulkaccountsbuy.com/buy-gmail-accounts/
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.
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.
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
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.
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.
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.
> Mainly privacy of communication doesn't always imply anonymity, through sometimes does (and has too!).
Anonymity is simply people not knowing who you are, not necessarily what you say. It's not privacy of communication, but privacy of identity.
I can post on the internet as Anonymous Coward, and those posts are public even though my identity is private.
I can encrypt an email and send it, and it will be picked up by all the relays. They can look up the source and identify me, but hopefully not read the email contents.
Just because you don't use your name doesn't make the service anonymous. Pseudo anonymous is still in the privacy bucket because there's still likely (given websites today) personal information associated with your account. True anonymity could be achieved, but it'd be difficult to maintain.
I said that the post I responded to was conflating two different types of privacy.
Who said things is different to what was said.
Bob and Alice spoke about something, is not the same as Anon to Anon "The government is listening".
One is the message and one is metadata. They are protected in different ways and leaked in different ways. Mixing the two means that you will probably not get the protection that you desire.
You state this distinction as if it's established, but it's not a definition I've personally heard explicitly stated before. If I read the introduction of the Wikipedia article on "privacy", I find the following:
>The right not to be subjected to unsanctioned invasions of privacy by the government, corporations, or individuals is part of many countries' privacy laws, and in some cases, constitutions.
So according to Wikipedia, at least in some cases, privacy is protection against the state. Where does your definition come from?
Sanctioned by the state, which the right to privacy should protect you from. The fact that your country habitually violates your rights doesn't change anything about the fact that you have a right to them.
Their breakdown is what’s parroted up and down comment chains on this site when it comes to privacy/anonymity, so I’m frankly not sure how you’ve missed it over the years.
That, and the terms themselves tend to invoke clues about the meaning. Privacy implies there is an identity, but it is kept hidden. Anonymity implies there is no identity established so there is nothing to hide.
We don't see much of the latter since most web services require an email to sign up, at minimum, which still leaves discoverable bread crumbs. The web services that require you to give up nothing to use them are far less popular, so I guess I can see why people might conflate the two.
I'm not sure where you're drawing your implications from, but that is not implied, to me. I frequently see the concept of privacy applied to situations where an entity isn't required to ID themselves for the sake of privacy.
The common description when contrasting anonymity vs privacy is that anonymity allows one to do things publicly without being ID'd while privacy allows one to do things without the public having knowledge. There is no implication or requirement that the private party has been ID'd by another other entity.
Privacy protects some things from the state, which is why the western world has the concepts of warrants and such.
But the concept certainly doesn't mean that a business is going to help you cover your tracks in regards to data you've already shared. (in this case, the recovery email address)
If you give out your personal information, commit a crime, and ask that person to help you hide, you're not asking for anonymity, you're asking for an accomplice.
I think that is the GP's point. Privacy means the data is reasonably hidden, though it still exists somewhere in a readable state. Anonymity means the information of who did what really doesn't exist anywhere.
In the case of governments, private data is only hidden until the government decides that it needs to look for it (or ask for it). Anonymity means the data isn't there, regardless of whether the government decides it needs to, and has legal justification to, demand access to the data.
Anyone providing anonymity is only an accomplice if they know your intent. Simply not collecting data doesn't make you an accomplice, not collecting data with the intent of hiding someone else's illegal behavior does.
I slightly disagree with your distinction. Privacy is about minimising the amount of data collected that's visible to anyone but you. Your data stays with you and/or only you can see your data, therefore, private. Anonymity isn't about the amount of data collected, but that the data collected or accessible by others can't be linked to you.
I could have been more clear there. I was specifically thinking about data that can identify you, not just data in general.
If I'm the only one in possession with data I don't really consider it data collection at all, at least in the context of privacy and anonymity. Other than that I agree with your clarifications here though.
You seem to be confusing privacy with practicality. In practice, nothing is ever secure, nothing is ever private and nothing is ever safe.
What matters here is what Proton promises and advertises to users/potential users vs. what it can actually deliver. I don’t know if Proton is more open about this, but hopefully this isn’t just buried in some long Terms of Service that almost nobody reads.
> Proton is incorporated and headquartered in Switzerland, meaning your data is protected by some of the world's strictest privacy laws.
This is the main statement from Proton about their privacy protection. They say they obey Swiss privacy laws. So if one has a problem with Protonmail complying with Swiss law, maybe one should complain to Switzerland.
As long as your secure world is not fully isolated but has any interactions with the physical world at all (e.g a human being somewhere receiving and reading your message with his eyes), then it's only a matter of resources allocated to trace you. You can pile up layers of "hops" through uncooperative jurisdictions -- this certainly helps to raise the bar but doesn't give you a mathematical proof of security.
That's technically and theoretically true but also largely practically irrelevant.
Consider a building or a server. You can absolutely make them secure. Sure, eventually, everything can be broken/bypassed/hacked/cracked whatever, but if there is no chance of that happening for the duration that the security has to persist, then it is secure.
> Consider a building or a server. You can absolutely make them secure.
I'm not sure it's a good example. A server that you build from off-the-shelf components will likely come with the IME, providing direct tcp-to-ram access. Motherboard manufacturers probably add their own backdoors on top. We know about Gigabyte because they were caught red-handed, but how many we don't know about? How many rootkits in the SSD firmware? In hundreds of other firmware blobs installed on your Linux server right now?
I'm not even talking about Open Source backdoors which are hard as they have to be done in the open. Hardware/firmware backdoors are not in the open, they have been around for decades, they have been found and confirmed numerous times and god only know how many were NOT found.
Building a secure server nowadays is an extremely complex task, only solvable at the government level perhaps and only an a few select countries, if solvable at all. You need full control over the whole supply chain that includes tens or hundreds of thousands of corruptible employees.
I think it's a fantastic example because it's flexible enough for us to extend to make our points.
You make a good point, as when I made my comments I was considering an 'average' usecase, typically wanting to guard against malicious attacks from unknown actors on the internet.
You're talking here though about absolute security against basically a state level actor. No one else is going to be dealing with exploiting backdoors in firmware for specific targets.
But I still maintain my points is correct, it just requires substantially more money. If guarding against state actors is the requirement, that can be met by having custom or at least verified (at every stage of manufacturer) hardware. Expensive, but far from impossible. As for software issues, that's why we have stuff like SELinux and SEL4.
So yeah, I maintain you can absolutely secure a server. You just have to be clear about what the threats you are wanting to protect against are, and for most people that isn't state actors.
With all "security" cameras and face recognition software and big data mining, which links many sources together, real world in developed world is not a place for revolution too.
Welcome do dystopia and hope that governments in developed world will not become too nasty (CCP-level nasty) too soon due to inertia.
Your take is just about the opposite of what anybody I know would mean by privacy, which is to protect your information from government actors primarily, for obvious reasons since the government is an actor that seeks out to harm the public.
> Privacy does not protect you from the state. Privacy is good enough to protect you from the public.
While I get what you are saying, that is a little too black and white for the entire field. Privacy can be used to shield whistle blowers from the state.
If you are doing battle with or an enemy of the state, much less an agent of the state acting in bad faith simple privacy will do nothing for you. Worse your misunderstanding of it is actually a vector, like in this case. The measures for anonymity you require will not incorporate fancy UIs, nice features, or even reasonable reliability at times because they will be sacrificed in the name of leaving no trace.