Is anyone else kinda hoping that GPG/PGP loses enough respect in the tech community that something fresh comes along that really solves a lot of the UX and security issues they have? (Acquiring keys, rotating keys, identifying compromised keys, and most importantly either reaches a large enough percentage of emails sent that usage of it is not in itself an immediate flag to monitor or can be implemented as a side channel not directly including the signature in the email payload itself.)
> Acquiring keys, rotating keys, identifying compromised keys, and most importantly either reaches a large enough percentage of emails sent that usage of it is not in itself an immediate flag to monitor or can be implemented as a side channel not directly including the signature in the email payload itself.
Kinda. But S/MIME has its own problems[0], mostly related to you as a recipient being unable to choose who is authorized to send you encrypted email (and so spam and malware filters don't work).
On top of that, GPG and S/MIME's support of encrypted-at-rest email is, imo, a fool's errand. Handing a payload of data to a third party that the recipient can eventually query to retrieve makes it much easier to grab a hold of and try to decrypt in the future. The same is true of SSL to an extent, but SSL traffic is much more voluminous, such that saving all of it to eventually crack and decide if there's anything worthwhile in it is unlikely.
The only real way to transfer private data between two users is to do it live with an ephemeral channel, whether that's in-person or via SSL or etc. The only value I see in GPG and friends is in verifying authenticity of the contents - signing the email - not encrypting those contents. Email has, and always will be, an open protocol, for better or worse.
> mostly related to you as a recipient being unable to choose who is authorized to send you encrypted email (and so spam and malware filters don't work).
That's a problem with all encryption anyways. Inspection has to be done at the end-user's device. So I don't think it's fair to hold that against S/MIME.
> On top of that, GPG and S/MIME's support of encrypted-at-rest email is, imo, a fool's errand.
If it can be done with E2EE messaging apps, sure it can be done with email. Long-term storage is a really difficult problem anyways.
> The only value I see in GPG and friends is in verifying authenticity of the contents - signing the email - not encrypting those contents. Email has, and always will be, an open protocol, for better or worse.
To some extent I agree. An ubiquitous deployment of digital signatures would already solve a bunch of problems and most of the rest are handled by transport encryption.
> That's a problem with all encryption anyways. Inspection has to be done at the end-user's device. So I don't think it's fair to hold that against S/MIME.
I don't think that has to be the case, though. Protocol negotiation is a thing; SSL negotiating the version of the protocol to use, HTTP 1.1 -> 2.0 negotiation, etc.
You could imagine a mail protocol that starts at an encryption level, then during the negotiation process when the mail-to-be-delivered provides a public key, the recipient server can check that key against a listing of keys accepted by the user, and if not included, attempt to negotiate down to an unencrypted version of the email.
The sender of the email could choose to not allow that downgrade and get an undeliverable mail error, or they could choose to allow the downgrade to plain text/html email. This could then be run through the standard spam/malware filtering as usual and the spam eliminated, while email that came from already trusted email can skip those filters because the user has already judged them worthy of accepting and keeping the communication private.
So I don't think that's an intrinsic difficulty of all encryption schemes for email, but...
> If it can be done with E2EE messaging apps, sure it can be done with email. Long-term storage is a really difficult problem anyways.
So first I'll state that I don't think all E2EE messaging apps reach the following bar, either, but the difference between an ephemeral SSL-encrypted communication channel and an email, fundamentally, is that the ephemeral channel won't be written to a disk somewhere, while the email will.
The window in which it is possible to get a copy, and the difficulty in obtaining it, is much more in favor of secrets staying secret in the ephemeral channel than it is in encrypted email. The data payload persists longer, and is likely encrypted by the same private key across many emails, so getting the emails and getting the keys are much easier than with the ephemeral channel that generates a temporary set of keys on each connection and never persists any of it to disk (so storing the communication with the hope of eventually grabbing the keys from the user's machine by virus or social engineering or just plain ol' physical theft doesn't even make any sense the same way GPG-encrypted email does).
> Is anyone else kinda hoping that GPG/PGP loses enough respect in the tech community that something fresh comes along that really solves a lot of the UX and security issues they have?
This already exists. It's just not a single, all-in-one tool - the answer is to use a tool that's fit for the specific purpose you're trying to accomplish (secure messaging, encrypted backups, encrypting application data, etc.)
There is not, and never will be, a modern one-size-fits-all approach because the entire industry has moved on from that model - over the last 30 years, we (collectively) have learned that it's inherently insecure to design a tool to do so many disparate things and expect people to use it correctly each way.
All of these use cases are encrypting files, some of them with a few extra steps as sauce. Stuff like whatsapp / signal is the exact UX that GPG has, fixed by instead ignoring everything that's hard (trust). The asymmetric cryptography is not fundamentally novel or interesting, and the end result of it could be applied to literally anything if they allowed you to touch your own things (which they don't). These modern solutions are build on the infantilisation of their own users, nothing else.
That's exactly the wrong way to look at it. Everything is potentially a file, but not all cryptosystems have the same use cases. The needs of message encryption (forward and future secrecy, for instance) are not at all like the needs of backup encryption (deduplication, for instance). This is one of the biggest things wrong with the PGP model of retrofitting cryptography onto problems, and why it has virtually never been successful at any of them.
I think it already has. Maybe not the underlying tech, but certainly for encrypt emails.
But I think the outcome of this is not "something fresh" but rather "giving up on the idea of encrypted emails altogether". We have far superior communication channels that are secure, easy and private today (Signal, Matrix, WhatsApp, iMessage); That problem is solved. Storing emails secure and encrypted is solved too, by providers such as protonmail, fastmail, tutanota and many others.
So what does GPG/PGP really solve still?
The one use-case that I strongly see it shine, is where mail-notifications are signed. I've only ever seen Kraken do this: Upload my GPG/PGP pub key in their web-interface, and have them sign and encrypt mails to me with that. It very much solves phishing and MITM on email-notifications (and password reset mails and such). Comes with two serious problems though: the UX on my client-end still sucks; e.g. I never managed to set-up PGP on my android client, so I cannot read their mails from my phone. "subject: Login attempt from X" body: garbled. And generation and rotation of the keys is as frustrating as ever. It certainly is not a feature for "my mom".
I think we agree[0] on this. Email encryption isn't ever going to be a thing because of the way email itself works. But email signing would help a lot. I still don't think GPG does this very well, though, because of issues with key rotation/invalidation/etc.
I wish it would just use TOFU ("trust on first use") by default. It's not 100% fool-proof, but actually does cover a large number of use-cases, and is certainly better than nothing.
UI:
"billing@paypal.com: we never seen this sender before, be careful"
"billing@paypal.com: this is verified to be the same sender"
"billing@paypal.com: ACHTUNG! THIS IS SOMEONE ELSE"
You can of course still manually add keys, and you can even do automatic or semi-automatic key rotation with some new header (e.g. "X-New-Key: [...]" that's signed with the old).
> You can of course still manually add keys, and you can even do automatic or semi-automatic key rotation with some new header (e.g. "X-New-Key: [...]" that's signed with the old).
Headers aren't part of an encrypted or authenticated body, so this is trivial to perform a key replacement attack against.
Sorry, is this a rhetorical question? I thought the fact that SSH does TOFU was (somewhat) common knowledge, which is why it spits out all kinds of scary MITM warnings when a host fingerprint changes.
If you're connecting to an SSH server for the first time and don't already have a pre-established host fingerprint, then yes: someone who controls your server's DNS records can redirect you to another SSH host, which you'll then (presumably) enter your password into.
> which you'll then (presumably) enter your password into.
One of the many arguments for using pubkeys so that's all they'll get. Neverthless, the rest of the session could still be anything, and agent forwarding should never be used for untrusted hosts.
I'm not sure what you were trying to say here about telegram, but they are completely unencrypted, for nearly all intents and purposes messages are stored in plaintext on the server. They just succeeded impressively in twisting that fact away via marketing.
None of which are anywhere close to as ubiquitous as email. None of which are well suited to long messages. Only one of those (matrix) is federated. Only one (matrix) wasn't designed specifically for use on mobile devices. Yes, the others can be used on a desktop, but the experience isn't great.
Hold on, there's a sleight of hand here. You're trying to compare all of email against WhatsApp. Now, it's possible that if you took transactional email out of the picture, and just stuck with interpersonal communication, WhatsApp could beat email. But that doesn't matter, because in this discussion, the figure of merit is encrypted email, and on that metric, every single one of those platforms on their own roflstomps email for daily usage.
Only Matrix is federated, like email. I really enjoy sending emails without opening an account for each recipient or being subservient to 1 stack provider for 50 years, with all the inbreeding that entails.
> Now, it's possible that if you took transactional email out of the picture, and just stuck with interpersonal communication, WhatsApp could beat email
Everyone I know uses email. No one I know uses whatsapp. A couple of people I know use Signal. A handful use iMessage.
> But that doesn't matter, because in this discussion, the figure of merit is encrypted email,
Ok, let's consider one case where encrypted email is commonly used: reporting security vulnerabilities. Do you really think any of these would be a good medium for that? Do you see companies or other organizations putting a whatsapp username as the contact in their security.txt?
I do want there to be a more secure replacement for email. But most of the newer e2ee messaging systems can't really fully replace email.
Is encrypted email commonly used for reporting security vulnerabilities? It seems like increasingly, more reports occur via bug bounty programs, or are disclosed publicly by the researchers, or are just sent as plaintext emails to security@ or whatever is publicly listed. When I've found security vulnerabilities in somebody's code, I can't think of a time I ever thought about GPG-signing my notice to them.
The fact they know no-one who uses WhatsApp is a giveaway of their demografy as well. In many countries "not having WhatsApp" equals "not participating in anything". In my country everything, from my insurance help desk to the coordination for a friend's birthday gift happens on WA.
Despite my reluctance to use Meta projects, I read and write far, far more WA messages per day than emails.
Yes: I think Signal is drastically better for reporting security vulnerabilities than email. I think if you're actually worried about operational security for accepting vulnerability reports, using email is practically malpractice. The fact is, most security teams, even the very large ones, are not especially concerned about operational security for inbound vulnerability reports.
From a security point of view, absolutely. But there are logistical problems. Currently, a signal account has to be tied to a cell phone number. How does that work when you want it sent to a team instead of an individual? There isn't a sanctioned API, so it is difficult (and unsupported) to set up an integration with bug tracking software. Not to mention that the reporter may not have Signal set up yet.
Most reporters don't have PGP set up, either --- far fewer than have Signal set up. But this is all kind of a moot point: the industry norm is to use plaintext email, and to make ad hoc arrangements (including voice calls) for the very rare cases where things are too scary to email.
Honestly these seem like pretty minor issues compared to the task of properly managing a GPG install.
How do you manage the keys? If you've shared them with a team, how do you ensure someone hasn't taken a copy? What if the key is lost? What if someone ends up replying to the thread without doing the encryption song and dance? It's just such a pain. I'd rather copy and paste something out of Signal and into my bug tracker a thousand times than have to deal with all the footguns of email encrypted with GPG.
>The fact is, most security teams, even the very large ones, are not especially concerned about operational security for inbound vulnerability reports.
There have been many attempts, usually formed by ignoring the inherent difficulty of creating secure communications while fundamentally being the exact same UX as GPG. It's genuinely incredibly tedious to see there is a new "alternative" and find out once again folks are over-promising and under-delivering.
I'm just saying, I've used and tried to get people to practice WoT with OpenPGP on the order of a decade or more. There simply isn't a demand for protected communications because normies haven't started suffering at the hands of government for online shenanigans yet.
After a while, you sort of want bad things to happen so society will move forward... Humans are so reticent to act to protect themselves from a threat they don't see or understand the capabilities of.
normies use encrypted communication way more than the cumulative historical usage of GPG or PGP; Signal, WhatsApp, iMessage, and now Facebook messenger all offer better privacy for the average person than GPG or PGP ever did, and are used by orders of magnitude more people.
It doesn't pass the smell test. FB has been caught numerous times mishandling data. Apple is a walled garden you can't trust, same with WhatsApp. Unless Signal is liberally licensed, we can't verify privacy there.
Also, using a phone number as an ID is a de-anonymizing technique. Industry absolutely does not do this correctly, or they wouldn't be a juicy source of analytics data. Governments court these companies to exfiltrate data they have on people. If the data were adequately protected, they wouldn't be able to do this.
Sending something over HTTPS is encrypted but it's not private to the other end. Nice sleight of hand but I actually understand what I'm talking about.
I read about the WoT and I found the idea fascinating, but I've never used it myself. Would love to hear anything you have to share about using it in practice.
When some muas announced Autocrypt support a few years ago I got excited again, but unfortunately nothing came of it. I havent been able to auto-update my key on my partner's mua, it seemed 'support' meant different things to different projects but none focused on the goal: making PGP encrypted email usable (and more secure).
There was a year or two where I actually began to receive autocrypt headers from random people and started encrypting with them.
Unfortunately, this momentum was completely killed by thunderbird, who decided to remove support and proceed to reimplement traditional manual email encryption :(
> something fresh comes along that really solves a lot of the UX and security issues they have?
I'm working on this! It's called Stamp (https://stamp-protocol.github.io/) and takes a lot of the issues I've had with PGP/GPG and creates a more modern refresh. It's definitely not simple but my hope is that having sane defaults and writing good interfaces will help with this.
Unfortunately it just went through a rearchitecting and the docs are horribly out of date, but the basic concept persists. In the current version instead of having different hardcoded key types (alpha, publish, etc), there's now the concept of "admin keys" and "policies." Policies decide what keys can do what as far as managing the identity, so it's possible for instance to have a policy that gives a key god powers, or a policy that sayd "if three of these four signatures match, the entire key and policy set can be replaced" (aka, multisig recovery machanisms). Also, in the current version, "forwards" have been entirely removed and replaced by claims.
The goal is to use this as a means to act as an identity in p2p systems. My issue with p2p systems is that they always punt on identity, making it a function of your device and some randomly generated keypair. That said, Stamp can definitely be used more generally.
Right now I'm focusing on the underlying network that syncs identities between devices and also stores identities publicly, circumventing the need for keyservers and all that stuff.
I'd love to see something displace GPG, particularly the "pipe to an external application" usage paradigm that's just awful in so many ways. At the same time I'm not ready to give up the only cryptosystem that we know to have actually thwarted the NSA in real-world conditions, particularly when so many of the proposed alternatives require absolute non-starters like publishing your phone number or using an unverifiable auto-updating client application.
But fundamentally there's no money in it. GPG is Like That largely because it's maintained by a grand total of one (1) guy, which is all the OSS community can afford to fund. Who's going to pay for a crypto platform, except when it's the CIA (or equivalent) sponsoring useful idiots?
reply