That's the whole point of age. That pgp is too complex and overloaded with features. By focusing on encryption only he can really get it right.
If that is the case, you probably want:
1. a long lived keychain
2. a way to securely load private keys into smartcards such that they cannot be stolen by malware
3. a strategy to recover lost keys
4. a strategy to migrate from one keychain to another one
5. a way to notify people/software to stop encrypting data to your old key
6. a way to switch between multiple competing software implementations with a long established spec
The PGP ecosystem has you covered on all points. Age does few of these, and none of them well.
Doing things the right way takes a bit more up front thought and time, and you will thank yourself later.
That said, for the sake of compatibility, keyfork keys can be used with any pgp toolchain, as well as with signify, age, or whatever.
What’s more, it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer. All that is needed for that higher layer to “compile down to” or emit some kind of key allowlist or denylist that can be consumed by the cryptosystem layer beneath it. The work-in-progress VOA[0] spec is an example of such an upper layer.
[0] https://uapi-group.org/specifications/specs/file_hierarchy_f...
Encrypted files are encrypted to a key. It could be a one time use key encrypted to another key as PGP and Age both do, but still there is a long lived secret a user must maintain somewhere, somehow, and have a strategy for backup, rotation, discovery, validation, etc etc.
> it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer.
There are a ton of other ways these problems could be solved. If we had a time machine we would go back and design way different tools and specs to address the problems PGP solves. We would redesign the internet too.
What I take issue with is people recommending age or minisign or signing with ssh keys when all of these just pretend the problems PGP solves do not exist, and thus set people up to fail.
Of course. I'm not suggesting that there's no need to have long-lived private key material. But that does not require some thick GPG-keyring-style concept (especially one that includes both public and private key material). Something like a directory of private keys (like with SSH) fits the bill here and yet bears precious little resemblance to GPG's system.
> have a strategy for backup, rotation, discovery, validation, etc etc
Again, I see no reason to bake this stuff (I'll call it "identity management") deeply into the cryptosystem itself. Especially because different encryption use-cases have vastly different needs. The identity management needed for a one-time message exchange between humans shares little structural similarity to that needed for authenticating OS packages from multiple parties. These two use cases are almost entirely disjoint, I daresay. To the point that any effort to devise a shared abstraction will only muddy the waters since there is so little intrinsic similarity.
> What I take issue with is people recommending age or minisign or signing with ssh keys when all of these just pretend the problems PGP solves do not exist, and thus set people up to fail.
I can agree with this for sure. If you need these various features, then age et al. do not fit the bill.
On the other hand, in cases where these systems have adequate functionality or can be shimmed up by other systems, they're lightweight and easy for users to comprehend.
Take commit-signing with SSH keys to provide verification mediated by GitHub. Everyone (lol) knows how to generate and manage an SSH key. Easy enough to set up git for signing with that key. Then GitHub uses its own identity layer to show users what commits are verified and which aren't. From the user's perspective, it's super lightweight, easy. When it comes to cryptographic signatures with long-lived identities, it basically doesn't get easier than this.
Of course, that GitHub example misses some features, and isn't perfect. But it captures a lot of the value of signing with a bare minimum of error-prone work for the user.
Your argument doesn't cohere.
I feel like the rhetorical sleight of hand PGP advocates too often fall back on is the idea that while there may be tools that do some of what PGP does, and those tools put together may comprise a superset of PGP's functionality, there is no one tool that does everything PGP does by itself. But that's the whole point. Part of what makes PGP so bad is that it's a Swiss Army Knife.
If a human focused cryptography tool gives a user no way to know if they are encrypting to the correct public key of someone else, or no way to distinguish a real signature from one of an impersonator, then the tools failed to do their job.
Age is maybe useful for personal encryption use cases, but it is no way a replacement for all encryption use cases of PGP, especially between humans. Let alone signing and authentication which would be a prerequisite to do this safely.
My guess is that at this point more professional environments (think on the level of "companies and projects") have integrated age and minisign than have integrated PGP, which is striking given how long PGP has had to demonstrate success. In 2025, if you built a new identity system for, say, code, virtual machine or container provenance, or secure messaging, your competent security team would very likely shoot you down.
This is just another instance of the same sleight of hand I identified upthread. It's actually bad that PGP does all this stuff, for the simple reason that different real-world problems have different cryptography requirements. For that reason, competently built systems don't do what the PGP ecosystem does, of fielding a Swiss Army Knife instead of a chef's knife or a table saw. Then the PGP ecosystem tries to ding those tools for not repeating PGP's mistake.
I know of no solutions even close to this for Minisign or Age keys that does not rely on centralized corporations like Microsoft.
> PGP does an absolutely dreadful job of key discovery, and further, there is no reason to couple one mode of "key discovery" to a signing tool. Different business domains will have different optimal key discovery architectures.
Here's how I expressed it to you:
> Again, I see no reason to bake this stuff (I'll call it "identity management") deeply into the cryptosystem itself. Especially because different encryption use-cases have vastly different needs. The identity management needed for a one-time message exchange between humans shares little structural similarity to that needed for authenticating OS packages from multiple parties. These two use cases are almost entirely disjoint, I daresay. To the point that any effort to devise a shared abstraction will only muddy the waters since there is so little intrinsic similarity.
This way you get git for change tracking on your secrets and who-has-access-to-secrets and key rotation and this can be trivially expanded to other forges.
Its easy to introduce age this way into any modern project whereas gpg would-ve been a non started on most teams I worked on.
disclaimer: this was mostly vibe-coded because I really did not want to work on this and wasnt sure if teammates would adopt it. Then it just worked, so stayed ugly inside
But this is what happens when people try to re-invent the wheel without thinking through all the problems the original solution solved.
Also I do put these systems to the test, regularly, and rest billions of dollars of infrastructure on them.
Anyone is free to hit up my team in our public channels with any PGP gotchas. Happy to help.
It is easy to point at past black eyes of any technology, but I stand by PGP for the use cases we recommend it for today as the least bad option for those use cases.
Also, Hagrid keyservers (openpgp.org) do email verification now and are a new generation of keysever built from scratch. The legacy ones are a mess and can be ignored.
Today though, Web Key Discovery, PGP DNS records,and Keyoxide are much better ways to discover and distribute keys and signatures now.
An engineer coming from a corporate world where everyone is comfortable with a model of centralized backups, centralized identity, and centralized trust is going to have a very different perspective than say, a Linux distribution maintainer, or those maintaining they core backbone of the internet.
I am closer to the latter camp, and obviously have my own biases here, but in spite of them I package Age in stagex, and we support it in keyfork, just so people have choices. Choices are always a good thing.
That said, it is my opinion that age does not even begin to approach the threat model or use cases PGP solves for. It does one thing, and it does not even do that thing as well as PGP does in most situations I can think of.
Just because someone is experienced in cryptography does not mean they have had significant exposure to environments where decentralized identity and trust are a hard requirement and where no alternatives to PGP exist, and where there is no customer service or IT team to bail you out, which really changes how we tend to think about these problems.
In my experience cryptography engineers that work on decentralized open source systems like Tor, blockchains, Linux distributions, etc, tend to strongly favor solutions like PGP as not "good" but the "least bad" option to avoid any single point of trust or failure.
Those that have spent their careers in the proprietary FAANG world tend to support using solutions like Fulcio or sigstore and using OIDC to let a central party sign for you with "keyless signing", which to me, is total nonsense. I assume anything that I cannot verify the integrity of for myself to be compromised.
Also a solution that significantly reduces attack surface enough to motivate a migration from PGP in all the areas it is used, and a specific strategy to migrate everything to it.
Also form a standards team to maintain the spec to keep all implementations compatible so this work is useful long term.
If all of that happened I would seriously evaluate it and likely even help promote it. Few understand the shortcomings of PGP better than those of us that heavily rely on it!
Until then I suggest improving upon what already exists, or at the very least stop steering people away from the best effort solutions we have today and all the hard work from hundreds of people that go into maintaining them for free.
in practice, few, if any, of your enumerated "wants" are valuable enough to outweigh their costs to complexity
this should be pretty clear from the fact that statistically nobody uses pgp