I was hoping their big song and dance over privacy would lead the likes of Gmail, Outlook, etc to adopt native PGP too.
Wishful thinking. :')
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?
But when it comes to true security, 90%, or even 99%, is so far from "good enough" as to be pointless.
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.
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 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.
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.
For anyone else that's curious: https://rfc-editor.org/rfc/rfc6376#section-3.7
(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.
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.
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.
At the end of the day, it's not a problem with the protocol.
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.
(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.)
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.
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 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.
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.
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)
Or does that not work?
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:
It's the only reasonable solution for proving your message X survived an intermediary. You have to do it regardless of message encryption.
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.
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 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.
> 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 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.
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.
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.
For more info on this see:
https://community.signalusers.org/t/proper-secure-value-secu...
https://community.signalusers.org/t/dont-want-pin-dont-want-...
https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin...
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?
The email client handles this.
1. User writes recipient address.
2. Server checks the address and asks mail host for encryption key.
3. Mail host sends encryption key
4. User continues writing email.
Similar to how UDP https works.
I'd call it Wave
https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
https://support.google.com/a/answer/10741897
https://security.googleblog.com/2023/06/gmail-client-side-en...
[1] https://www.spiegel.de/international/germany/inside-the-nsa-...
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].
[0] https://www.spiegel.de/international/world/leak-at-wikileaks... - not that they necessarily used PGP, but the problem is the same.
[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.