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".
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.
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.
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.
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.
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".