A well-intentioned ideal from a bygone era.
Elaborate
https://www.latacora.com/blog/2019/07/16/the-pgp-problem
Recommendations: https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/
We don't need to keep elaborating or re-litigating the same discussion. The PGP idea of "one tool to rule them all" is a terrible cryptography design, and the world is better off the sooner we stop trying to make it work.
* https://articles.59.ca/doku.php?id=pgpfan:tpp
By what I saw, there wasn't really anything anyone would care about in https://gpg.fail/ . The GnuPG problem actually declined to respond to some of them.
There isn't one cryptosystem that does all these things. For messaging you want a carefully-defined notion of forward secrecy and post-compromise recovery, along with a careful decision about repudiation/non-repudation (1990s cryptography doctrine would suggest you just always want nonrepudiabilty, which turns out to be disastrous for privacy). For backup, you want deduplication and content addressing. For packages, you want transparency logs. You almost never want long-lived keys, but you often want identify binding.
PGP solves basically none of these problems, and offers instead a 1998 API (I'm not kidding, I thought about what year to pin it at) to basic cryptography primitives.
But PGP is useful if both sender and receiver agree to use PGP.
Anecdotally: this works until you add a third person who responds to the thread in plain text, with everything threaded beneath. Or when you do that by accident.
Applied cryptographers will tell you to use Signal or any other E2EE chat.
I think SGX is a red herring in this context. You can find it risky or not, but it's (1) not material to Signal's E2EE property, and (2) materially better than email, which sends all contact metadata in plaintext, regardless of whether you try and encrypt your message bodies. Bringing it up in this context seems like a category error.
Any time this topic comes up, here and elsewhere, I find that most discussions revolve around different understandings and misunderstandings what people mean when they say “PGP”, and rarely lead to anything beyond that. - no this is PGP no you’re wrong that is PGP and so on and on…
The expectation is that anybody who ends up with the encrypted copy would have an impossible time trying to decrypt it without, I don't know, millions of dollars worth of compute per year for decades to throw at it or something like that.
(The idea of trust networks is not bad. But PGP’s implementation of them is bad.)
The packet format is awful, full of complexity, backwards compatibility mess, and serious security problems.
The spec is pretty awful in that a lot of the complexity is due to keeping compatibility with things that are a terrible idea. And also in that the general concept of a long lived key turned out to be a bad one.
The library or lack thereof IMO cripped PGP/GPG back when it was relevant. It's nigh impossible to make tooling for it, or it was until Sequoia showed up, which was extremely late. Things like doing stats on keys, or doing anything but what the binary wants to do were terribly painful until Sequoia.
The Web of Trust was an interesting idea for a while, but failed to transition to the modern internet.
By the time you fix all the things what remains looks nothing like PGP, so it amounts to "all of it is bad".
What's crazy is when it was concieved, we didn't have trusted strong cryptographic primitives. We did have DES but it wasn't trusted. We did have some of these crazy ideas that we all would have "secrets" and you might put those secrets encrypted on a disk in a vault and you'd not even want the feds to get them. Now we have all sorts of much more vetted crypto primitives, but the idea of actual secrets you'd keep in cold storage is largely dead. You're spot on that modern use cases need different APIs and tools and specialized solutions.