Before anyone jumps ship on ProtonMail because they didn't read past the headline, by "Rewrites Your Emails, the author means that ProtonMail doesn't support user-applied PGP signatures because of the way they've decided to architect their automatic signing and encryption system. ProtonMail isn't rewriting outbound emails in the sense that the average person is probably thinking. If you're part of the 99.9% who doesn't sign their emails or verify signatures, this issue is unlikely to actually matter to you.
That said, Proton's response to this issue is joke.
Hi - crypto team lead here. I'll hijack this comment to try to explain what Proton Bridge is intended to do, and why it doesn't work the way OP wants.
Bridge is a proxy which hosts a local IMAP and SMTP server, and takes "normal" unencrypted and unsigned messages from desktop MUAs like Thunderbird, signs and encrypts them, and then sends them out. Note that this requires changing the MIME message somehow.
OP writes:
> Everything was great until I decided the other day that I’d also like to do PGP signing on my outgoing messages.
The "intended" way to do this is enable the setting in Proton Mail that says "Sign external messages" :) That way, Bridge will sign them for you. (Internal messages are always signed.)
> Tough luck, bucko, we’re the SECURE email company, you’ll upload your private key to our servers and you’ll like it!
FWIW, private keys are stored encrypted on the server, we don't have access to them.
But yes, the entire goal of Proton is to handle PGP for you, without having to set up PGP encryption and signing manually on all of your devices. I know that the HN audience is fully capable of doing so, but our goal is to make it easier for everyone else :)
> It’s absurd that there’s no way to disable this, no option to tell Proton “if you see a multipart/signed or multipart/encrypted message, just leave it the hell alone.”
IMO, if we see a multipart/signed message, we should still encrypt it whenever possible, not leave it alone. But note that normally in OpenPGP, signing and encrypting is a single operation. It's possible in PGP/MIME to sign a message first and then encrypt it, but we don't support sending that way at the moment, though we could of course add that in the future. But in any case, that's the reason we currently recommend signing using Bridge rather than manually using gpg or similar.
> FWIW, private keys are stored encrypted on the server, we don't have access to them.
I'm always bothered by statements like this because it appears to be skimming over if the provider can perform cryptography with the key. My understanding is that those keys are only decrypted in the users apps/web browser, not server-side. Is that right?
You need to trust that the provider doesn't perform additional operations along side legitimate user triggered actions, which I believe PM handles.
Even if all the decryption resides in the app/web browser side, they can just silently change the code and inject some scripts to hijack the encryption routine.
Although they are open-source and can be scrutinized by anybody, it does not means that's what is run on the server side.
(Just say they have the capability; no accusation)
So at the end of the day, the question is whether you trust Proton or not. Encryption might not help in that case.
Yeah. For web, I've been advocating for something like "Source Code Transparency" (somewhat analogous to Certificate Transparency) in the WebAppSec WG at the W3C. The idea would be that if you could verify that the source code you're getting is the same as what everyone else is getting for a given version of the web app (and has been published in an append-only log of sorts), it would be much more difficult for us to try to compromise any given user without detection.
On mobile, to do such an attack we'd have to collaborate with Apple or Google to do it, which IMHO seems infeasible - but nevertheless also there a "Binary Transparency" feature of sorts might be valuable.
> I've been advocating for something like "Source Code Transparency"
Thank you for moving the web forward. Proton mail does a lot of things well, and there's more to do. I was auditing DANE support and PM was one of the few I found with support.
Correct, private keys can only be decrypted client-side, the server doesn't have access to the password that they're encrypted with. Otherwise it wouldn't be end-to-end encryption, IMO :)
> > Tough luck, bucko, we’re the SECURE email company, you’ll upload your private key to our servers and you’ll like it!
> FWIW, private keys are stored encrypted on the server, we don't have access to them.
This is frankly fucking ridiculous. Users (including me) have been requesting a change to this for years. It's thanks to this bullshit that ProtonMail's key feature for me is just 'isn't Google'.
It's not entirely trivial because for internal messages we don't store them in PGP/MIME format, for performance reasons (e.g. to make it possible to fetch the body separately from the attachments, or one attachment without the others, they are signed and encrypted separately, unlike PGP/MIME which signs+encrypts the whole message in one go). So, if we serve the messages "as-is" it's unlikely that the email client would display them correctly. We're considering trying to standardize (something similar to) our internal format at the IETF, to enable other clients to implement such a format, but again it's not something we can ship overnight.
tbh the reason I expected this to not be a thing is the reason you have given (consequences), hopefully a standard that suits everyones needs comes through at some point. Appreciate the work.
Why can't you just detect that it was already signed with a valid signature, especially if you have the user's public key?
PS: the lack of threading support in your mobile apps is embarrassing, it's been like this for years. No I will never use your web client. Stop trying.
Correct. You lose customers on purpose when you don't have basic features that the competition has had for years, and when, after years of delays, you release a new version of your app that still doesn't have this feature.
I don't know why you think this is some sort of gotcha. Other than you think having standards is too entitled.
> It’s absurd that there’s no way to disable this, no option to tell Proton “if you see a multipart/signed or multipart/encrypted message, just leave it the hell alone.”
which, as I said in my response, I disagree with the first half of that. Our goal is to (automatically) encrypt messages whenever possible, and leaving multipart/signed messages alone doesn't reach that goal. So I proposed two different solutions to what OP wants, one of which is already built into Proton Bridge, and one which we could add in the future (but which would be more effort than the one OP proposes).
It was good enough for Snowden. Apparently not good enough for the people here who want a centralized server that requires phone numbers run by a hip guy with a cute name.
Ya, either the parent post is troll, or he read the Vice article from 5 years ago and thinks it nullifies PGP? Not sure, but is it perfect? No. But I don’t think Snowden is a security LARPer.
I assume this was meant in reply to me. I'm not trying to tell users what to do, rather I'm trying to explain the type of usage that Proton was designed in mind with.
I'm actually more shocked knowing that they drop plain text if there is a mime-encoded part (e.g. HTML). Just verified that all mails imported from GMail and all newer mails I received in PM only have the HTML part now, while GMail shows both HTML and plain text parts in message source. Great, now if I want to use a text-only client to read those mails in the future, I won't be able to.
Now I honestly wonder, how did they think this is something okay to mess up? Is there just no usable email hosting service for someone that want their mails not touched and also stored securely? Like, this is not even going to save storage space for PM - I'm paying for my storage.
Office365 does the exact same thing. I think to the majors once email crosses into their systems it becomes an object of their own that is no longer an email as such. They may partially reconstruct it for you as a courtesy...for now.
> how did they think this is something okay to mess up?
I'm speculating but this has the smell of enshittification. Somehow this is saving them money while making the product worse, and they're hoping not enough customers notice to matter.
> I especially dislike their smarmy we-know-better attitude when people complain about it.
I'm happy to see this called out. Don't explain to me that I'm holding it wrong. At minimum admit that a shortcoming on your end prevents me doing what I want and think about if or how it's possible to change that.
Not really, that's just one of the opinions, another could be to have opinionated defaults with an option to change anything, so highway isn't the only alternative
no, configurable only captures the second part, there are plenty of projects that are configurable, but have bad defaults, leaving everything to be set up properly by every single user instead of doing tha config upfront (and expressing an opinion re. how it should be configured)
For example
- being able to change an encryption protocol is "configurable"
- Setting the default to be unencrypted so that the user chooses it is "unopinionated defaults".
- Setting the most modern encryption protocol by default is "opinionated defaults"
All defaults are opinionated defaults. The fact that you consider a particular default "bad" supports that claim more than anything.
To your point, setting the default to be unencrypted reflects the opinion "this layer of the stack shouldn't be responsible for handling encryption unless the user has no other choice".
Yes, which is fine as long as the vendor makes it known upfront that it’s their way or the highway.
This is a valid business strategy in my experience especially for B2B enterprise SaaS, where you know your product works very well if used to solve a specific set of problems using your SaaS tool in a way that you, the vendor, prescribe.
At our company we tell prospective customers that if they don’t like the workflows we demo to them, they shouldn’t buy our product because the customers who like our product are the ones who use this workflow, and people who don’t like our product use strange workflows we don’t recommend.
I think the problem is when the customer isn’t made aware of the opinionated workflows/features/etc until after the fact.
> I've learned to avoid software tools that proclaim they are "opinionated" which usually means it's their way or the highway.
What is a good example where software is described by its maker as opinionated and where it results in "their way or the highway"?
I'm asking because all software need defaults and no software can do anything that all users would want, so the software maker has to make choices of what they offer (i.e. reflecting the maker's opinion).
By using Black, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.
Black makes code review faster by producing the smallest diffs possible. Blackened code looks the same regardless of the project you’re reading.
The entirety of MacOS. The number of cases where you must use it "Steve's way or the highway" are legion. Changing MacOS default behavior involves one of several mechanisms:
1. Changing a preference with a GUI editor. Only a small percentage of all defaults can be changed this way.
2. Changing a preference with "defaults write..." and hoping the change will stick the next time you upgrade the OS.
3. Change the default for one usage but it will revert the next time you do that operation. Many examples wrt how Spotlight searches work in the Finder.
4. You can't change the default at all. Example: Themes. Last time I checked there were two, and nobody can make others.
Ruby on Rails? Doesn't mean Rails sucks.. tons of people are very productive on Rails. It uses Ruby idiomatically in a way that I would wish to break out of, which would be difficult and counterproductive, because of its strong opinion that I shouldn't. But I don't want to work in Rails, and Rails doesn't miss me.
Prettier which is a Ecmasceipt formatter. It basically doesn't have settings as a feature. You can change some things like eol and if you want to use tabs or spaces. Everything else is more or less as it comes, and they want it to be that way to stop discussions in the teams using it and to not allow feature creep.
I call Pettier a compromise tool, noone is happy noone is too mad when you force it on checkin etc
Prettier also came to mind, and I'm usually pretty happy with the "it's formatted this way, deal with it" approach - but I also would like the tool to behave predictably with updates. Prettier had some changes in 2.5 related to multi-line-classes (namely, forbidding them), which in turn made it unusable for projects with tailwind usage, as it now forces extremely long lines in some cases. (Especially for elements that have styling based on multiple breakpoints and a darkmode variant, you're hitting >120 chars easily).
I know that you can go for descriptive classnames and "@apply", but I was still miffed about a change like this in an already existing tool, with a lot of community pushback and no compromise in sight.
So for prettier, it wasn't just "format your code our way or else" - which is a good approach for a formatter, see also gofmt - it was "your current set up doesn't work anymore, tough luck".
This hasn't been my experience. I've been able to throw together a .prettierrc.js file that gets me everything I want to tweak from the default (line length, quote types, etc.).
Out of curiosity, what did you find to be something unchangeable?
Wireguard. If you want to use different options for its encryption, you can't. I don't think that's a bad thing, but for example someone wanting FIPS certification might.
Every time one of these threads come up I like to share my experience attempting to use protonmail for my business:
Protonmail charged us for every email account, whether or not they were active. When an employee left the company, we would disable their email address but we wanted to keep records of their email history. Of course, exporting email from protonmail is difficult to the point where you need an engineer to do it.
So I emailed protonmail saying "hey, do you think you could add a feature where email addresses can, say, be permanently disabled and then we don't pay for them any more?" They replied with a typical protonmail brush-off.
I was already frustrated with the service because their search is worse than a simple substring search and after a few years of using an email provider for professional use you sometimes have to find old conversations. So I canceled the account and closed the privacy.com card.
A year later I noticed that the (luckily closed) card was still being charged monthly, so I tried to log into the old account to see if there was a problem and the password (stored in a password manager) didn't work. I emailed them to let them know there was likely a bug and their support agent argued back and forth with me about it before finally demanding my credit card information (which I didn't have, the card was closed a year ago) to stop billing me. I just stopped responding at that point.
In my mind the fact that they are so hostile to their users is a big red flag. I think it's bad practice to trust people who indignantly dismiss reasonable questions from paying customers with private information.
I understand your frustration, but it sounds to me like your business case isn’t what Proton was created for.
IMHO, Proton is meant to keep conversations completely private between recipients. I’m more surprised that you can still access a former employee’s email at all.
They paid for the account in the name of their company, for company uses, with company money. If that's not account ownership then please define what is.
I’m not disagreeing. Just saying I would have expected Proton to side with the individual users of the account over who paid for it. Not saying I’m right, just that I’m surprised to hear that’s not the case.
That's not how Proton works. If you have an organization, you have complete control over all the accounts. I can reset passwords for any email address in my organization and read all their email if I were so inclined. He's not talking about individual accounts which are how you describe it.
For non-private subusers, you're right, but for private subusers, you can only read new emails after resetting the keys, you can't read existing emails. I.e. you can take control over the email address, but not access existing data.
Hmm. Longtime proton VPN user here, was considering finally leaving gmail for proton mail but maybe that’s not such a good idea. What would you recommend? This is for personal use not business.
I'm fairly happy with fastmail. Wanted to slowly move away from Gmail, tried proton mail, but it has weird ways to setup 3rd party apps iirc. Stepped over to fastmail and have had pretty much zero complaints. I am using a custom domain name, but I assume the experience is the same using @fastmail
> It’s been mostly acceptable, but a few months ago the Android client started mangling emails – if I hit “send” too soon, it would send out only part of what I’d typed; I had to wait 10 seconds or so after I finished typing before hitting send to be sure it sent.
Oh my God, i thought it was just me! I've had multiple emails to doctors and financial advisors get cut off this way when i clearly remember typing the whole thing out and i was honestly wondering if all the medications I'm on (for cancer) were causing me to have brief hallucinations while sending emails or something like that.
Hey, mail product lead here : we're aware of this specific issue which affects a few users and are actively working on a fix. In fact, we've been rewriting the whole Android app which should make it more reliable and easier to use: it should come out later this year.
Until then, if you experience repeated sendings issue in the Android Proton Mail app, you can always use the web app (https://mail.proton.me) from any device.
"We're rewriting the whole app to fix a pretty serious bug that's been around for months, and please hold on a few more months" is probably the worst possible response.
IMHO this is really a "drop what you're doing and fix it" type of bug, even if it affects only a small portion of all users because it's such a critical high-impact bug, and any fix really shouldn't have to involve a complete rewrite.
Am I reading this right? You won't work on an immediate fix for this very severe bug, and instead they will have to wait until a complete rewrite is out?
This has been going on for months, and the rewrite will just introduce new bugs. That doesn't sound like the correct solution to a data integrity problem.
I remember I had one of the early Android phones and there was a bug where if the phone had been sleeping for too long (i.e. with the screen off) the alarm either wouldn't sound or would come on late. Try explaining to people that you were late because your alarm was faulty, they will just think you're making excuses.
It affects newer Android phones too. Built a meditation timer app. Alarm sound way played too late, when i switched it on. The power saving mechanisms that came later seem overly aggressive.
Yep had a lot of bad issues because of that too. I'm currently looking for another provider where I can use reliable solutions (just a real email client that does imap/smtp and handles gpg).
I'm still surprised Apple hasn't had a stab at making the PGP process seamless. I always imagined they'd generate keys on the device, sync via iCloud and publish public keys.
I was hoping their big song and dance over privacy would lead the likes of Gmail, Outlook, etc to adopt native PGP too.
There are many, many use-case problems with PGP and email, to the point that most serious security people just don't bother with PGP. It's relegated to niche and die-hard users. The problems are so many that it's better to use an alternative messaging platform that is built from the ground-up with encryption in mind, like Signal.
For example...
1. what happens when you send an encrypted email, and the recipient forwards it?
2. What happens when the recipient replies? Will your original email be included encrypted, or decrypted? Most likely the latter, meaning the same cleartext is now present in two messages.
3. What happens when you email more than one person? What entity handles the encryption for each recipient?
3.a. what if only some of your recipients support encryption? What's the point of encrypting if you're sending some in the clear anyhow?
4. What happens when you email a mailing list, with unknown participants?...
5. What should be canonically encrypted? Just the message body? What about the subject, which is a header of the email? What about any other headers?
5.a. Oh you just want it signed? Again, what is canonically getting signed? How does that survive the many transformations the text receives in a conversation?
1) It's decrypted and forwarded re-encrypted with the receiver's public key.
2) It's decrypted and re-encrypted with your public key.
3) Same thing that happens right now? Two separate emails get sent out each encrypted separately with the receiver's public key.
3a) It gets sent unencrypted. Frontend client warns the sender.
4) Separate emails get sent out with the receivers' public keys.
5) Everything except the receiver's single email address. Optionally, everything except the receiver's and sender's email address for spam filtering.
5a) Everything.
Not sure why any of this would prevent Apple, Gmail, and Office365 from implementing a transparent PGP encryption layer. If just those three entities worked this out, the vast, vast majority of emails in the western world would be encrypted effectively. Just because some emails wouldn't be well-encrypted doesn't change that this would be a huge benefit for privacy.
All emails are basically signed these days via DKIM by your mail service. Each server along the chain should also be signing them too, so your whole path is known and validated. You can validate those keys via DNS.
True story, I was an expert witness on a case once where I showed how the other guys were submitting forged emails into evidence -- by using DKIM signatures/hashes. That was probably some of the most fun I've ever had.
I’ve always wondered about tampering of digital evidence like that, how much it might happen and not be detected, and what the penalty would be if it were.
Part of the work was explaining that a print out of an email is just a representation of the email, an actual email contains headers (like a digital stamp) that explain how the email got to where it is (in gmail -- "show original" -- that naming really helped, btw) and without it, you just have a piece of paper with words on it. The equivalent would be printing out the body of a newspaper article without the author or source. You have words, but you can't prove that it came from that newspaper unless someone else can corroborate it.
Email has been around long enough that it's hard to imagine someone submitting an email as evidence without including full headers. Do you think that it was done intentionally to trick the court or was it just incompetence?
Good point! It used to be possible in outlook, but it looks like MS took that option away for years (WTF). Recently (within the last year) they said they brought it back. In Outlook 365 for Mac you should be able to right click on a message and select "View Source" to get the message with the full headers. That's the same way people did it in Outlook for Mac 2011
I agree, most people have no idea headers exist (beyond the short headers), but I expect lawyers and law enforcement to know better. Handling digital evidence is not new and at technology's timescale email is ancient.
It costs money and attention to insist on full headers. Unless the lawyers think there's something worth digging for, technical details would be omitted from copies just like they are in your email GUI.
And, on the other hand, either party can demand the other prove via live witness that the evidence is authentic, reliable and useful. If the witness isnt credible, the document can be excluded.
The DKIM signer selects a list of headers (h=) to be signed, but the body is always implicitly included (and thus not listed). I was confused because I thought there needed to be a flag to include it, and had never seen such from Gmail or others.
Unless you meant how Protonmail specifically handles it (maybe they do it this way), I think general principles are different in some regards.
> 3) Same thing that happens right now? Two separate emails get sent out each encrypted separately
I thought the email gets encrypted to multiple recipients (at PGP level), then MUA submits one single email with all those Cc and Bcc addresses. Then the SMTP service sends the same copy (that every recipient can decrypt) to every recipient's individual mail server (one message with per mailhost).
Not the way you've described it. I don't think anyone wants to trust SMTP server with their private keys (one single reason I do not use Protonmail).
> 4) Separate emails get sent out with the receivers' public keys.
I'm afraid this won't work. Mailing lists and encryption are quite incompatible. The whole point of a mailing list is that your client doesn't know or bother to know the recipients - and they can come and go. And if you specify every recipient it's just (3).
I'm not aware about any standard on how to implement email lists/archives/newsgroups with encryption (so one joining can read past messages) and forward secrecy (so kicking someone out ensures they can only read what they have already seen).
> 5a) Everything.
Problem with existing email infrastructure is that MTAs and MDAs do a lot of transformations on the headers part of "everything". So just saying "everything" isn't exactly informative. I think the best approach is to send a full MIME-encrypted message as an attachment in a minimal envelope (so just From/To/Subject). But then there's the infamous SPAM problem - and I'd really wish it would've worked, but sadly filtering solely based on sender-receiver pairs doesn't work in reality (or I wouldn't have to maintain and train rspamd on my servers).
I was proposing that as a back of the napkin sketch for how Apple+Gmail+Office365 could implement it. But this description of ProtonMail is hugely illuminating.
This wasn't a description of Protonmail - I don't have much experience with them specifically and they may do some things differently, but of one's casual email service, like how people use PGP with existing mail systems.
I also do not claim that description to be 100% accurate - it's been a while since I've used PGP with email in practice, so I might misremember something. But to best of my awareness, this is how things are done today.
In my opinion, the main three problems with PGP today are: 1) lack of good no-frills "just works"-type tools; 2) issue with email metadata (at the very least, to/from addresses) being impossible to encrypt by design; and 3) abundance of haters (and they have a lot of right arguments, although many just boil down to the tooling issue and how it's easy to shoot everyone's legs with the current tools) who claim PGP should be buried (all together with email) - which is not exactly wrong.
(1) doesn’t preserve sender identity: the receiver is stripping the original signature and/or ciphertext, meaning that B’s forwarding of A’s email to C is not verifiable with A as the original sending identity. Depending on the context, this either doesn’t matter or makes the entire scheme useless.
(2) and (3) have similar problems.
(4) is a TOFU-ish scheme, meaning that it’s trivial for an adversary on the wire to replace the keys.
(5) doesn’t work, full stop. E-mail wasn’t designed with encrypted headers in mind. Trying to shoehorn these things together leads to all kinds of weird misplaced user assumptions around what is signed or not, etc.
1) When I send an email to someone, why would I care whether they can forward it and prove I wrote what they forwarded? I want to prove I wrote my emails, not theirs. If Apple/GMail/Office365 feel this is important, they can include a signature for the decrypted text -- this could even be togglable. Then when you hit "forward" on an email sent with that toggle enabled it includes the signatures of the earlier senders in the chain for provability of those content blocks. But this isn't how DKIM works and I don't think it really matters. If I'm wrong about it mattering, see above for a quick solution.
2-3) What? Not seeing the problem here? Do you also think encrypted emails need to prevent someone taking a photo of their screen with their phone and sending the photo to someone else? If we can't prevent screenshots and copy/paste of decrypted content, we just shouldn't encrypt anything? What is the logic here?
4) It would also be signed by DKIM and/or the sender's private key, so your proposed MITM attack is not trivial at all. Are you aware of DKIM and PGP signing? You're trying to establish authority with "Email wasn’t designed with encrypted headers in mind [so you can't do it]" but that authority is undermined by not demonstrating understanding of modern email.
5) By the magic of controlling 90% of all end-user email in the western world, a consortium of Apple, Gmail and Office365 can do whatever they goddamned well please.
Why are you letting perfect be the enemy of the good? Regular email doesn't preserve sender identity when forwarding, and why should that even matter for encrypted mail? Encrypted clients can disable including the original email in a reply, which is totally unnecessary nowadays. And it's okay if headers are unencrypted as long as the client knows it's unsecure. All I'm seeing is a strictly better system than cleartext mail which might have holes around the edges but none that can break the integrity of single-recipient encrypted mail, which is what most people use encrypted email for anyways.
This is the rare case where the "perfect is the enemy of the good" logic doesn't apply. Encrypted email is secure messaging. Secure messaging is life-or-death (or at least life's fortune) for many ordinary people who rely on it. The only reason encrypted email is taken seriously by nerds is that none of their messages matter; it's LARP security, a thing done performatively as a social signal, and it doesn't matter if it's safe because getting hit with the LARP sword doesn't kill you.
The right way to think about secure messaging and the compromises we should be willing to accept with it is avionics or radiotherapy software. Safety is practically the only thing that matters; if you can't provide it, there's no point in talking about how convenient, open, federated, or standardized it is.
I don't follow. Simple single-sender-single-receiver would still be 100% secure so use that if it's life or death. Forwarding and multiple recipients can come with a warning that it will be unsecure. Same with the headers. Anyone actually relying on it to be secure would understand the opsec necessary to maintain this, just like any other platform.
1. It leaves metadata unprotected, which is usually just as valuable if not more so to investigators.
2. It leaves the subject unencrypted, which isn't even metadata --- it's message content.
3. It's effectively plaintext-by-default, which is why everybody who has ever used encrypted email has seen someone reply to an encrypted email with an unencrypted response that includes a transcript of the encrypted message.
4. It's based on long-term secrets and a cumbersome secret exchange process with no forward secrecy, something no other secure messenger does, because that configuration makes it just a matter of time before someone loses their key to an investigator and compromises the entire transcript --- put differently, the configuration of cryptography in secure email encourages investigators to simply record all encrypted messages in perpetuity, since they'll eventually get the one key that unlocks all of them.
These are disqualifying attributes that cryptography engineers would never accept in any modern design. The only reason they're tolerated in email is that almost everybody who uses encrypted email is doing so performatively, so that it simply doesn't matter when their counterparty replies in plaintext; it's a party foul, not the end of someone's life.
Part of this is, I think, that PGP came to popularity in the 1990s, during a time where the Internet was itself kind of a toy, and if you had a threat model, it probably involved someone you'd pissed off on EFNet IRC. If your only adversaries are script kids who are going to own you up for your mail spool, PGP does a great job!
The problem is, real-world adversaries, now that the Internet is as prolific and important as the telephone, don't play by IRC script kid rules. So much so that the plaintext content of a PGP'd email often doesn't even matter; they just need the source and destination email addresses and the time the mail was sent, to determine where to roll the van up to in order to beat the plaintext out of the recipient. Or, in the US case, 18 USC 1001 you into federal custody.
Because it’s not good, it’s bad. “Let the perfect not be the enemy of the good” applies to schemes like the Web PKI or phone numbers as identities in E2E chatting schemes, not to things that outright don’t work.
(You’ll note that even the simplest single sender case here assumes both key distribution and stable keys for users, neither of which PGP makes easy.)
I don’t understand what warrants have to do with key distribution.
The problem here is much simpler than that: you can’t encrypt to me if you don’t know my key. PGP doesn’t give you a sound way to get my key; every mechanism offered by the larger PGP ecosystem is either broken or disabled due to persistent abuse.
PGP protects against warrants if done well. But if gmail.com has a system to force-push new keys (which it basically has to do, receiver of key could get option to reject but everyone will just click "yes, accept updated public key for this contact"), then a warrant can force Gmail to utilize their existing system to push a MITM key and intercept encrypted email.
Why are we proposing schemes that are broken from the outset?
As others have pointed out: Signal (among others) does not have these problems. These problems occur because email was not meant to be encrypted (or signed); efforts to do so result in these kinds of convoluted “maybe secure, maybe not” models.
If we want people to be able to communicate privately, we should be encouraging them to use protocols that are meant that purpose.
I'm not sure signal actually solves the key distribution issue, it re-issues keys for users semi-often which have a feature to verify the new keys, but most users won't. It also has a potential frontend distribution problem through the App Store (apple/google could be compelled to distribute a compromised Signal App to specific users).
Theoretically at least Android has a TOFU-like system where the developer signs the app (although Google also has a product where Google manage the keys which developers can sign up for). That doesn't help people who are specifically targeted as it's within Google's control on most devices to change that via updates to system components or to hold back critical security updates selectively via the Play Store channel but it does raise the bar a bit.
I am really suspicious of signal, just because it's promoted so much.
I think it is secure, if, you don't install it via google and you actually do verify your contacts, but the NSA might relying on the fact that most people will not.
That's why it was proposed iCloud or whatever big tech provider does the key distribution, just like they do for iMessage. It would be a big win for Apple if they actually cared about privacy. But maybe it's just a pipe dream.
People keep proposing this as if federated key distribution is easy, and as if iCloud could with sheer force of will can just do it correctly.
There is a reason nobody serious is trying to make email encryption work: secure messaging is already incredibly hard when you control every piece of the system; with email, you control absolutely nothing.
I could easily be misunderstanding PGP, but for (1), if A signs an email with B's public key (but does not sign it with A's private key), the intent is to make the email readable only by B but not verifiable that A sent it. If A wants both (they want to have the sender (A) verified and to ensure only the recipient (B) can read it), they then also sign it with their private key. Order does not matter.
If B wants to forward it to C, they can strip off their own (B's) encryption, leaving A's (optional) private key signature, and send that to C.
C gets an email that contains a message from A which is (again, optionally) signed with A's private key, where if it was signed they can verify the A sent that part of the message. (Headers and newline mangling aside)
>If B wants to forward it to C, they can strip off their own (B's) encryption, leaving A's (optional) private key signature, and send that to C.
That could work. The PGP format is pretty modular. You could just strip out the content packet and signature packet. People don't do it because it would be confusing. Things like encrypted email list servers would be more likely to retain signatures.
Believe it or not, the possibility is actually something people have complained about in the past:
> Not sure why any of this would prevent Apple, Gmail, and Office365 from implementing a transparent PGP encryption layer. If just those three entities worked this out, the vast, vast majority of emails in the western world would be encrypted effectively. Just because some emails wouldn't be well-encrypted doesn't change that this would be a huge benefit for privacy.
The challenge is key handling, especially the commonality of multidevice access to the mailbox. If you want to do this transparently, the only place you can store the key is... right next to the mailbox, so that anyone with access to the mailbox has access to the key. In other words, you're forced to limit the number of people who can read the message to anyone who has access to the mail server. But there's an easier way to limit the number of possible readers of a message to that set of people--just encrypt all the links involved in sending a message. And that was done about a decade or so ago, and happened pretty transparently.
Oh, and there's another problem. Encrypted emails break a lot of email features people like to rely on, such as spam filtering, server-side filters, or server-side search. (Assuming you don't just give up and give the server the keys.)
Encrypted email is a solution in search of a problem.
> If you want to do this transparently, the only place you can store the key is... right next to the mailbox, so that anyone with access to the mailbox has access to the key.
If the client can generate a unique public/private key pair for every sender/recipient combination, the key wouldn't need to be stored on any server, just ephemerally transmitted one time over TLS/SSL. But that would have the downside of if you lose all devices with the key, you can no longer read those emails. There's partial solutions for that, like your own collection of public keys could be encrypted with a passkey/passphrase and uploaded to the central server, but then if you lose your passphrase, Gmail still can't help you read past emails.
I agree that good key distribution is probably impossible.
I'm pretty sure an on-device LLM / statistical model could filter spam pretty darn well though.
> Same thing that happens right now? Two separate emails get sent out each encrypted separately with the receiver's public key.
Minor correction, but this is not true. The mail itself is encrypted symmetrically and only the key is encrypted with the receivers public key (this is true for all cases). In case of multiple receivers, the key is attached multiple times, encrypted with the PK of each receiver.
>3) Same thing that happens right now? Two separate emails get sent out each encrypted separately with the receiver's public key.
Wouldn't this mean you lose the ability to show all recipients to all recipients? E.g. multiple To or Cc entries seem... probably not possible, since that would imply also sending to them? At that point it isn't "multiple recipients of an email", it's "multiple emails", and that's an only-sometimes-minor difference.
I definitely do not know email in enough detail to be sure though.
In 4), what you describe about sending email to a mailing list is not clear to me. Are you saying that the mailing list will have a public key that’s used for encryption (by the original sender) and that the mailing list software will decrypt and re-encrypt with the public key of each member when sending the emails? If yes, then if some members don’t support receiving encrypted emails, those would certainly go unencrypted. In other words, there’s no guarantee (except in small and close groups) for this to work as intended.
#4 would be absolutely be "hard" for a lot of reasons, but all those reasons are just "because standards", not technical. Apple/GMail/Office365 together have more than enough influence to establish new standards with modern sensibilities.
> The problems are so many that it's better to use an alternative messaging platform that is built from the ground-up with encryption in mind, like Signal.
I'm not sure signal is what people who really care about their security should be using. Signal refuses to update its privacy policy to reflect the fact that for years now they've been permanently storing sensitive user data in the cloud. At this point I consider the fact that the very first sentence of their privacy policy has been a lie since 2020 to be a dead canary.
That, combined with their very unclear and misleading communications surrounding the data collection along with the dropping of highly popular features (the ability to handle unsecured SMS/MMS as well as secure communication) and inclusion of sketchy crypto features nobody asked for, makes me suspect even more that Signal may be telling people as loudly as they can to look for alternate solutions.
To anyone unaware that Signal was collecting and forever storing sensitive personal data in the cloud, that should tell you everything you need to know about how trustworthy it is.
I'd say the problem of PGP and email is that it suffers from a "90% of features is good enough" mindset that is prevalent in open-source (which otherwise isn't a bad thing!)
But when it comes to true security, 90%, or even 99%, is so far from "good enough" as to be pointless.
> The problems are so many that it's better to use an alternative messaging platform that is built from the ground-up with encryption in mind, like Signal
I mostly agree. Although I don't know of something that can really replace email. Signal for example is not great for long form content, is kind of difficult to use on a desktop, is tied to your phone number, doesn't have a way to programmatically send messages (besides unsanctioned third party clients), and doesn't have a good way to group messages into conversations or threads. Most other e2e encrypted system have similar limitations.
Matrix is perhaps the most promising I've seen for replacing email. But the biggest problem is the network effect. It doesn't matter how good a system is if no one you know uses it.
This is not entirely true. I am not allowed to mention their names but there are a myriad of companies that use PGP in their software integrations. It is very heavily used for B2B in the financial world. That isn't to say that devs don't shake their fists in anger when trying to do QA testing on software/library matrix of tools that businesses use with PGP, there is plenty of that.
On a personal level I have taught many in my circle to use GPG with Thunderbird as it is really just a couple clicks to set it up and no effort to use it. Mozilla did a great job making that easy to use though I have no doubt that prior implementations had soured peoples experiences to the point of not wanting to try it again.
Some of your examples are real issues though. Mailing lists are a pseudo-problem in that it doesn't really make sense to use on a public distribution. I've seen it used on Usenet in that fashion long ago but adoption was low for that use case and people complained they could not read the messages not intended for them and that they should use email directly to the people it was intended for instead.
What happens when you email more than one person? What entity handles the encryption for each recipient?
Apple is actually somewhat serious about privacy and security; PGP is much closer to the “performative” end of the privacy and security spectrum than to the “serious” end.
Indeed. The client could maintain a vector search table that contains "unencrypted" data from emails, but the table itself could be separately encrypted on-device to the same level of security as the rest of the iPhone/MacBook/etc (T2/TPM/HSM chip). Definitely a client problem.
Oh, yes. I never claimed otherwise. But if you’re a user of Apple Mail and are looking for a solution for encrypted mails today, you should be aware of this.
Apple is already in hot water over law enforcement access. Just imagine the political kerfuffle if they started supporting a messaging technology that even the NSA couldn't break[1]...
You're assuming that using PGP for all email is a good thing. I'm unconvinced that's the case.
Email is already encrypted in transit in most cases, and modern TLS has benefits over PGP. A big one is forward secrecy -- if you leak a TLS key, you haven't leaked all your past messages. But if you leak a key for an encryption scheme that doesn't support forward secrecy, you leak everything, as WikiLeaks found to their cost[0].
Mitigating this issue -- especially in the context of email -- is hard.
Also, PGP encrypts message data but not message metadata. Transport encryption still protects the per-message metadata, but adding PGP doesn't help.
Lastly, for this note at least, adding PGP into email in a way that is seamless will almost inevitably still involve some level of trust in your email provider. I'm all in favour of end-to-end encryption, but not at any cost. New protocols can have new capabilities, but for email my judgement is that your personal security boundary should include your email server. TLS for encryption in transit, DKIM for attestation of authenticity, and trust that the person you're communicating with has similar levels of trust with their mail host[1].
[1] I recently sent emails with bank data in them to my solicitors, something that just seemed wrong on so many levels. But my mail server will[2] decline to send mail to their server without validated TLS, and however I give them the information it's going to end up in their O365 environment because that's how the company works. Submitting it over SMTP over TLS is no less secure than over HTTP over TLS.
[2] Because I have an advantage over many people who want email security, in that I run my own mail server and can configure it to require TLS for domains that I know support it. I'm not quite at the point of changing the default and only supporting plain text transport for explicitly-allowed domains, I need trust on first use and better observability of failures before I dare risk that -- and I'd use TLSA except that DNSSEC is annoying and so no-one else uses it.
> you’ll upload your private key to our servers and you’ll like it!
What's the point of PGP if the e-mail company has the private key? Just security as the e-mail is being sent over the network + signature verification?
Sharing the private key is an odd way to keep secrets.
A friend of mine wanted me to send them encrypted .gpg files due to being remote but not having the files on their person. They found that downloading some of these files from failed to download.
After testing and submitting a bug report, they were told that ProtonMail assumes attachments are encrypted with the user's address keys, and tries to decrypt them (the .gpg extension is stripped when recovering/recreating the original file name).
The biggest surprise was ProtonMail had suggested for my friend to import their private key corresponding to the public key for the attachments as a workaround. My friend did not agree to do this.
Use a low entropy things (I guess user's password would be not larger than 20 characters nowadays even using password managers) to encrypt a high entropy strings (PGP key).
We derive a (key-encryption-)key from the password using a password hashing function / key derivation function (bcrypt, although we're planning to switch to Argon2) before using it to encrypt the PGP key. This is fairly standard practice, it's what password hashing / key derivation functions are designed for.
The crypto refresh of the OpenPGP standard also has Argon2 built-in, exactly for this purpose, so that you don't have to do it manually. (RFC4880 also has "string-to-key" functions built-in but they are fairly weak so we don't rely solely on them.)
All of that being said, it's still important to choose a strong password or passphrase, of course; if you choose "123" then it's gonna be guessed instantly no matter how strong the hashing function is (well, unless it's so strong that even logging in becomes too expensive...)
The main goal of password hashing functions is to tip the balance towards making it too expensive for an attacker to guess your password (as long as it has let's say "medium entropy") while still making it cheap to log in.
> Be advised that Protonmail is generally known to be a pretty bad email host. They will munge up your outgoing emails and your patches may fail to apply when received by the other end. Not to mention their mistreatment of open source and false promises of security! You should consider a different mail provider.
Glad that I jumped out the ship only after one week so I can get full refund lol
Ah, but somebody could man-in-the-middle your request and change it around so it looks like I said some really dumb stuff (dumber than what I actually said, I mean)
Ok, and then? Would that be so bad? It would be found out pretty fast if it had any real world consequences. You could just comment on HN saying that your words have been maliciously modified and that would be the end of it. Or you could tweet about it. Or use any number of ways to voice your point of view.
> My solution was to set up the Proton Bridge in a VM on my NAS, then used rinetd to forward incoming connections on the IMAP and SMTP ports to the bridge (which only listens on 127.0.0.1). I then set up tailscale on that box and on my phone; with that, I could connect any Android email client (I like FairEmail) to my Proton account. I was also accessing it from Linux using Claws.
That sounds like a big fraction of the complexity of a self-hosted setup.
Every time email is discussed here, people familiar with self-hosting point out that it’s nearly impossible to get Gmail to not flag your mail as spam. (I have no idea, but it’s a recurring theme.)
Google and Microsoft both were easy to deal with for me, and I even have a domain with a newer TLD (bar). DKIM+SPF is all it seems to take.
My host was also on Spamhaus' blacklist, but no one else's. I'm not sure it mattered, but they were nice enough to remove it and reply with a snippy email about how reluctant they were to do so. No surprise there, folks at Spamhaus would block their own mother.
Self-hosting email is just not that hard. It does take a bit of work, but that's why it's called DIY.
It was easy for you because you were lucky. My server has SPF and DKIM and DMARC, à grade of 100% on mail-tester, and was on zero blacklist.
I NEVER could send an email to a Microsoft email address and have it end up in the inbox. It was systematically flagged as spam. Microsoft's answer was to subscribe to some shitty, shady third party service to maybe, MAYBE change my reputation.
They're probably talking about True Scotsman's Self-Hosting whereby your MTA is not configured to go through someone else's SMTP forwarding host, but is slugging it out on its own, sending mails directly to target mail domains, and is sitting on an IP address that doesn't have reputation for sending mail. Self-hosting like it's 1992.
The wise man accepts that using a reputable forwarding host for sending is still valid self-hosting.
I use Mailgun, but all the big name providers should be pretty much the same for low volume sending. Unfortunately my 9 year old VPS IP was already on a spam list when I got it, not sure if it falls off eventually.
Nope! I use my local Big ISP, and have for 13 years.
To quell your worries about a prospective service, you can try them without rushing to relying on it. Just point a mail client at their SMTP host and test for a while.
I imagine if you have your DNS records set up strongly enough it would warm up to your MTA's IP address rather quickly, but I have not tested this for a few years now.
Yes and the same with Microsoft's consumer domains like live.com, outlook.com and hotmail.com . It's a total pain, they don't trust you unless you send a lot of email. Even if you never send any spam.
The plural of "anecdote" is not "data", but I'll throw my hat into the ring as not having deliverability issues with Gmail. I can't attest to how easy or not it might be for someone who hasn't been running a mail server for nearly 20 years, though.
I'll throw my hat in the ring for iCloud+, which I migrated to from Google Workspace (using imapsync) and may be a good choice if you use iCloud anyway. Apple's been hosting email for a few decades now, and they've been a reliable, no-muss/no-fuss email host for me.
One of my favourite features with iCloud mail is generating new email addresses for each service, in a very integrated straight forward manner
Before iCould I used to to this manually with my own mail
In the first iteration I had a catch all address, so I could invent any new email address and it would arrive to me. This was plagued by spam because any conceivable user @ my domain would be delivered to me.
In the second iteration I manually created aliases in the config file for my mail server when signing up for new things. This was additional overhead and annoying.
iCloud thanks to the integration into Safari and apps is so smooth with this. I just click the “hide my email” button and it generates a new unique email for the place I am filling in an email address.
This isn’t a feature of iCloud mail - Apple will do this no matter who your provider is. They create an address and then just forward emails for it to your real address.
Unfortunately when it comes to the masked email feature in iCloud+, there are finite number of emails they let you generate for that, which means you’ll end up sharing between services. It’s something like 150, and I can personally say I have about 500 or so right now in fast mail for different logins, and I haven’t even fully migrated yet.
> when it comes to the masked email feature in iCloud+, there are finite number of emails they let you generate for that, (…) It’s something like 150
Do you have a source? I did find reports saying that it was limited to 100 during the beta but that the limit has since been lifted. People are claiming almost 350 addresses with no cap.
Indeed, if there's no limit, you probably want to not document it, lest you tempt someone with too much time on their hands to test if unlimited really means unlimited.
I know it's swiss etc, but the honeypot tactic is not new. Protonmail could totally be infiltrated or controlled by an intelligence agency under the guise of "we offer you privacy".
I don't like conspiracy theories, but when it comes to escaping government electronic surveillance, Snowden made me realize that tinfoil hats are not so ridiculous.
How come self hosting email is such a pain in the ass? I use Proton, its okay, I feel better about it vs Gmail/Gsuite, but its no where as good, feature wise. If I could self-host email, I'd feel good about my tool stack, but I simply don't know enough about the protocols, web/mobile clients, managing network and in/outbound issues, I give up before seriously considering.
I'm also self-hosting on a different domain. The actual software stack is easy. It's dealing with the blacklists that's hard -- I submitted a ticket to spamhaus, but of course there's been no response after weeks. I guess I have to figure out how to tuck a $50 bill into an email if I really want to get off that list...
If they start taking those bills, they will want to get them often.
Self hosting is a lost cause for e-mail unfortunately. You either get overrun by the amount of creatively formatted spam, or all of your e-mails are dropped despite having perfect SPF+DKIM+DMARC records and long-time owned domains.
Especially Microsoft has a horrible record of dropping e-mails everyone but big enough companies. Guess which software is the most popular choice in business e-mails: Microsoft Exhange. So no job applications, no communication with the various government offices, no business enquiries but loads and loads of spam that uses all possible codepoints in UTF.
In one sense, I could kind of understand it. If they can eliminate 99% of all spam by only accepting mail from a handful of domains, and if those few domains happen to be what 99% of their users get (wanted) email from, it's hard to justify the expense and hassle of accepting mail from anyone else. That said, considering how much spam is sent from gmail and other large mail providers it seems like the actual numbers probably aren't as supportive.
I don't agree with it, but I could understand it. Because of the spam/blackist problem, every ISP I've worked for has ultimately either stopped providing email service or outsourced it.
> How come self hosting email is such a pain in the ass?
Because Google and Microsoft have a monopoly on email.
Because of that, they don't have to play nice with anybody else and can make you jump through any arbitrary number of hoops since they hold most of the users.
It's very uneven, and which domain(s) you have trouble with will not necessarily be the same as anyone else's problem domains. I also self-host, no mailing lists, personal mail only, and my one and only deliverability problem is AT&T. Google? OK. Comcast? OK. Charter? OK. Hotmail? OK. Any @sbcglobal.net address, or anything else associated with SBC d/b/a AT&T? Fahgeddaboudit. I can check the public DNSBLs, and there's no problem. I can jump through AT&T's hoops, and get their automated replies, and next week I try to send to a person on AT&T and find I'm back on their secret blacklist.
Just like if I see a company or individual talking about “unbreakable” one time pads, my inclination is to either see them as selling snake oil or else really not have an understanding of modern encryption best practices, every time I see companies or individuals talking about PGP, I get the same feeling. PGP may have been pretty good in the 1990s, but it should be considered bad practice to use it now. It is very easy to misuse and likely has vulnerabilities in practice at least in the way people use it.
Okay, I'll bite; what's the problem with one time pads? You have to exchange pads, but otherwise I was rather under the impression that they are unbreakable.
One-time pads are completely unbreakable if you use them correctly.
Using them correctly is impractically difficult for most people.
Your key has to be as long as the sum total length of all of the messages you send along that communications channel, and it has to be completely random. Reusing any key material, or having a less-than-random key, breaks the security. Losing your place in the gigantic key you're using doesn't break security, but it makes the result impossible to decrypt unless you try every possible offset within the key to see which one gives a reasonable decryption.
Therefore, someone selling a "one-time pad" security system isn't really selling a one-time pad system at all, because people wouldn't buy an email encryption solution which required them to generate, distribute, and keep their place in an impractically large key.
It's possible to come up with scenarios where a one-time pad is a good solution. Spies have used them in the past and are likely using them now. But they're impractical and they're used as a buzzword by scammers.
Wouldn't there be software to keep your place in the key? I don't see how the key is "impractically large" if it's only the size of your original email.
While we're here, (and if anyone could chime in and refine or otherwise pick apart my analogy), it's impractical in the sense that it still requires us to take care of all the key and session management business in the real world, which is why AEAD systems and the like are necessary (in order to reliably and safely construct "one-time pads" under the hood).
I've always considered the OTP to be (not in some strict, rigorously correct sense) more like an ideal, theoretical/abstract cipher, much like how a Turing machine, generally unconcerned with a practical limit in tape size, is a sort of idealized, abstract computer.
What do you mean? Is the concept that even if the one time pads are "information theoretically secure", they are not unbreakable, because of issues with keeping secrets in practice? For example, it doesn't matter how good your encryption standard is, if the enemy has root on your keyboard controller.
I have been a paying customer for many years, but have told myself that I would eventually move to a self-hosted server. Maybe it's time. Luckily I have been using my own domain name!
I configured SPF/DMARC records for those domains, sign outbound email with DKIM and run the outbound server side in cloud data centers. That helps. Seeing the server logs also helps identify failures and diagnose why mail doesn't get accepted.
I suspect that this isn't a big issue for them considering how small the userbase is that will be going through the steps you did to sign using your own keys.
My setup is a little unusual with the shenanigans to allow multiple clients to access a single Bridge instance, but "run Bridge on your Windows desktop and point Thunderbird at it" is a pretty well-advertised use-case in their own docs/advertisement... and Thunderbird has PGP built-in, to the point where it's actually got its own key management stuff and everything.
> Thunderbird has PGP built-in, to the point where it's actually got its own key management stuff and everything
This postdates Proton Bridge, btw. But yes, probably we could do more to play nicely with it. But, when Bridge was created, using both Thunderbird and Proton to manage your keys was indeed not an expected or intended use case.
If someone else has the key, it's not safe encryption. It's only as safe as the entities holding the keys. Do we know that they won't sell? Be forced? What happens if they get hacked?
Now it's not your security you have to monitor, but theirs. And you can't control theirs.
Isn't that the same argument for the receiver of a PGP email? How do you know they won't sell your email, be forced to, or have memory stealing malware on their machine reading all emails?
It pains me to say it, but I'm leaving ProtonMail as soon as I can get round to it. I think I'll go to Fasthosts.
Never mind this pgp stuff that 1% of people find concerning, the current Android app is terrible at the basics. Half way through drafting a reply it closes your message and drops you in the inbox. Half the time it doesn't send, just boots your email into drafts where it sits forever, until you go and resend it. It also prematurely sends. The search is a random email finder now. It is hopeless.
That said, Proton's response to this issue is joke.
https://github.com/ProtonMail/proton-bridge/issues/26