Age only covers encryption. It does not cover signing, ssh, web of trust, hierarchical keys, key discovery, etc. It is in no way a replacement for a modern PGP keychain.
Ignore GnuPG which is a shit show stuck in the 90s. PGP != GPG
For a modern long lived personal PGP keychain use Keyfork on AirgapOS which gives you a secure 24 word mnemonic backup, optional split backup across redundant smartcards, and a separation of a CA key and daily driver subkeys on smartcards all done correctly so you do not have to think about it. I would suggest a Nitrokey Pro due to open source rust firmware, though Yubikeys are supported.
From there you can use your smartcard for ssh, password management, git commit signing, etc. and make your key easy to discover without impersonation using keyoxide to have all your services, domains, etc attest to your key, as well as any humans who vouch for you.
A proper PGP keychain is a long lived digital passport first, that has encryption and authentication subkeys.
Even if you ONLY care about encrypting files presumably you want to be able to decrypt them far into the future, with confidence no one else can do so.
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.
age has Yubikey support. The idea that the PGP ecosystem "has you covered" on all these points is a bold claim. Certainly people talk about all these things, but when that system is put to the test, it rarely holds up. See for instance the keyserver fiasco.
Barely. Age has Yubikey support with no reasonable long term key discovery, backup, or rotation strategy as far as I can tell. All things modern PGP tooling supports.
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.
I think even brilliant cryptographers can be wrong, or acting on strong biases formed from a limited perspective. In this case I think they have not thought about personal cryptographic key management and how people use tools like PGP in the wild well enough.
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.
I think Filippo Valsorda has in fact thought pretty hard about the issues you're talking about, and that, by contrast, the track record of the PGP community on those same issues is pretty dismal.
I think the tldr of their point is that Filippo thought a lot about cryptography but not about actual users or their requirements. What he thinks are cruft are actual features that users depend on
If I am wrong I challenge you to point at a well specified replacement for PGP with a diversity of competing implementations as a decentralized cryptographic identity and trust system for open source software supply chain signing, authentication, and peer to peer encryption with a variety of smartcard generation, usage, and backup solutions better for every situation PGP is used in today.
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.
I'm not the one insulting Filippo Valsorda, for no apparent reason (any of your points could have been made without criticizing him), when he's not present to defend himself in this thread. The onus is squarely on you here. You won't succeed, though, so I don't blame you for not wasting the time.
It’s unclear to me any stateful keychains are implied here. The decrypting system has N number of keys available. It tries to authenticate the ciphertext with those N keys. If the ciphertext authenticates, then return the decrypted cleartext.
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.
> It’s unclear to me any stateful keychains are implied here.
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.
> but still there is a long lived secret a user must maintain somewhere
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.
Wait, how does minisign "pretend the problems PGP solves do not exist"? Minisign is an example of a purpose-built tool designed specifically to address a problem PGP attempts to solve. We're now talking about two different tools each of which addresses something in PGP's scope. If we keep fleshing out PGP's scope, we'll keep finding more tools like this, because very few people operationalize PGP and lots of people have the problems PGP attempts to solve.
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.
Minisign and Age entirely dodge the actually hardest problem with humans using cryptography, that PGP puts front and center: identity and public key discovery. You cannot just skip these!
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.
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.
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.
Abusing ssh for signing is a silly thing to do in most cases when modern PGP tooling covers this and so many other use cases with established standards.
Also, again, use keyoxide which is a modern decentralized alternative to keybase. You can vouch for yourself to bootstrap trust.
OpenSSH keys were only meant for signing OpenSSH connection handshakes. They were meant for authentication, not signing long lived data. This is why PGP has distinct authentication and signing subkey types which can have different policies and permissions.
Using ssh authentication keys to also sign software is a total hack, and worse, means you are now using a single key for multiple distinct use cases without a subkey system, CA, or rotation strategy, or the ability to revoke a key for one use case without compromising others or forcing a full keychan rotation.
Telling people to use a single private keypair for many unrelated use cases has always been short-sighted cryptography advice and still is.
I get that gpg UX is remarkably bad and makes everyone want to run screaming from PGP, but modern tooling exists now and for all the things the PGP spec got wrong, it got a lot more right.
Watching new solutions get wrong the few things PGP got right as an answer to PGP is kind of infuriating.
There are not many reasons for signing without a strategy for key discovery and verification so others can verify your signatures are really yours and not that of an imposter.
SSH Authenticaton subkeys are widely shared publicly on every git host I am aware of. If you use a separate key for signing than you use for authentication, then you throw away the only established SSH key discovery method.
Now you solved the overloaded key problem, while making key discovery worse.
Everyone seems to be trying to re-solve problems with ssh keys that PGP actually solved reasonably well.
Isn't this more of a theoretical problem, rather than a practical one? In what situations do you want people to discover your key? You create a key pair for Github, upload the public key, and you're done; you can securely communicate with Github. Nobody ever has to discover it. Do they?
> In what situations do you want people to discover your key
Just to name some of the most common use cases I have:
1. When people in my orgs want to encrypt sensitive information to me, e.g in encrypted password databases over git.
2. When prospective new clients or security researchers want to encrypt sensitive requests to me via email. Have some in my inbox right now from today.
3. When people want to verify that commits or code reviews I signed on security critical software were really signed by me, and not masquerade malicious code as mine in a rebase, etc.
4. When people want to verify that public reproducible builds of artifacts I maintained are built by multiple maintainers.
These use cases all rely on a well published set of public keys shared with the public in ways with sufficient history and signatures so no one can impersonate me or other maintainers, or make it possible to easily trick people to encrypting data to keys that are not really ours.
I sign 100% of my commits, and 100% of all artifacts I maintain etc. Anyone claiming to be me on anything important without signatures from my very well established and easy to verify public keys, are not me.
A PGP key is the only standardized cryptographic passport for the internet and if you don't attach your work to an easily verifiable key you are one compromised account away from having your online identity used for supply chain attacks.
All major linux distributions and the core infrastructure on the internet is anchored in the PGP keys of few thousand people that put in the work to maintain well published keychains.
The only alternatives anyone have proposed are use Fulcio and let Google sign everything for you as a single point of failure for the internet. Hard pass.
Meanwhile with solutions like keyoxide, anyone can form confidence my key is mine trivially without relying on a central party:
> A PGP key is the only standardized cryptographic passport for the internet
I think this rather gives the game away.
For people for whom PGP is important, their PGP key is their identity. And there is a community of people like this. But it's small--I'd guesstimate maybe a million people or so at best, a true rounding error in terms of the internet.
For most people, however, their online identity is generally tied around one of a few core providers. The de facto identity for open source is GitHub, for better or worse. Do I like that we've moved to centralized identity management? Not particularly. But it is telling that in the shift towards identity management as a concept (e.g., OAuth2) in the past decade, PGP hasn't played a factor.
And in all of your passionate defenses of PGP, where you've complained that things don't support the PGP identity model, you've never really addressed the issues that a) most people don't have a PGP identity, b) PGP identity doesn't provide any practical value over existing identities, or c) things already work well enough with other identity models, that PGP identities don't integrate well with.
It's hard to know how these pieces fit together, especially if you have a fuzzy mental-model of the objectives and potential benefits. Is there a gentle introduction you'd recommend?
There are many ways to use PGP just as there are many ways to use openssl or any other cryptographic suite of tools.
For most individuals seeking to establish a long term durable personal keychain they want others to be able to externally trust and verify easily, I would suggest the following, which is more or less what most people in my circles do:
1. Buy a smartcard with touch support such as a Nitrokey 3
2. Ideally buy 3+ backup smartcards at the same time
3. Use Keyfork on AirgapOS booted on a laptop you trust to generate a 24 word mnemonic and split-encrypt it to 3+ smartcards (or write down mnemonic on paper if you lack budget for 3 extra smartcards)
4. If using backup smartcard set, split them up across 3 secure locations, or if using a raw mnemonic put on durable storage such as cryptosteel, and put that in tamper evident storage such as in a vacuum sealed bag with confetti with pictures you have copies of elsewhere.
5. Use keyfork to derive a PGP key and load it into your smartcard
6. Setup forced/locked "touch" requirement policies on all "slots" on your card so you must tap for each use (malware cannot do this, but easy for you to do)
7. Publish public key to keys.ogenpgp.org
8. Publish public key on your own domain name using Web Key Discovery
9. Use keyoxide docs to establish keyoxide profile with every internet platform you control attesting your key fingerprint is yours to make it easy for others form confidence that all of those are you, and your key is yours.
10. Major bonus: use QubesOS and map your smartcard only to an offline vault VM that prompts you for each use, and which security domain on your system wants to use your key, so malware is unlikely to be able to trick you even if your development environment is compromised.
From there you can use your provisioned smartcard with an openpgp smartcard capable ssh agent on your workstation for git signing, git push, ssh to servers, password management with password store, signing artifacts, thunderbird for email encryption, etc.
We plan on writing up a lot more public documentation for this sort of thing as the public docs suck, but we have helped thousands of people with this sort of thing.
Pop into #!:matrix.org or #keyfork:matrix.org if you want any help or advice for specific use cases.
A partially complete set of docs for different threat models is in progress at https://trove.distrust.co
There are many ways to use PGP just as there are many ways to use openssl or any other cryptographic suite of tools.
This is a very bad thing, because it is not in fact the case that there is one cryptosystem equally suited to all these tasks.
That you chose OpenSSL as your corroborating example is especially funny, because there is exactly one thing that OpenSSL is actually well-suited to doing (setting up TLS sessions), and then 20+ years of people getting themselves into grave trouble trying to get that library to do other things.
You spend a lot of energy steering people away from PGP, but what is your alternative to solve the same problems with the same threat models?
What do you want to shift the entire software supply chain security foundation of the internet to use instead and how?
Complaining the existing solution is not good enough is easy. Making things better and educating on current best efforts without creating centralized points of trust is hard.
Did you not read the post I linked upthread? You were quite confident in refuting its claims, so I assume we shared an understanding here.
Update
It looks like you drastically edited your comment after I replied to it, in ways that change the meaning of your prompt. That makes it impossible for us to continue discussing anything.
It’s not because WoT necessarily doesn’t work, but people simply don’t need to verify digital signatures. Whatever needs to be done is done internally by apps.
Dark web runs on PGP. People with no technical knowledge use it. Nobody has broken their communication. Not that this is a good use case, just saying bums can use PGP too!
The biggest use case is currently software signing. Like you would verify a master key for a project under TOFU model, once through several channels. From there, verifying software signed by keys signed ultimately by that master key is done easily and securely.
I like the idea of AirgapOS; "just turn off the network" has always felt a little dissatisfying.
That said, if you're already in the GnuPG ecosystem, https://incenp.org/notes/2015/using-an-offline-gnupg-master-... will cover you for pretty much everything here except the mnemonic backup using baseline tooling. I presume you can get a shell utility to pipe your key in and get that mnemonic version out if you'd like.
> I presume you can get a shell utility to pipe your key in and get that mnemonic version out if you'd like.
Not possible as GnuPG does not expose access to the cryptographic seed.
That said a mnemonic you generate and backup with keyfork is entirely compatible with GnuPG should you still want to use it as a client for keyfork-provisoned smartcards.
You can also use that same mnemonic to generate any other cryptographic keys you want for any purpose, including Age.
Keyfork only uses modern ECC PGP keys supported by the spec, prioritizing smartcard use, and using BIP32 KDF from a 256 bit mnemonic seed.
Nothing else comes close to the broad compatibility PGP offers. Just need to ignore legacy ciphers.
I suggest looking at the links. Latacoras take on this is IMO wildly out of date (6 years old to be fair).
PGP powers the core software supply chain security trust layer for the Linux distributions and tooling that power the whole internet and the standard does get updated.
I think you should read the post. It's mostly not about things implementations can improve about the PGP ecosystem on their own.
Then, I think you should talk to professional cryptography engineers. I'd be interested if you could find even one who believes the PGP ecosystem should be kept going. My distaste for PGP is not an idiosyncrasy; it's something I learned from cryptographers, who fucking hate PGP.
I read it when it was first posted and my team and I have personally done a lot to address some of the more fair points like UX. Keyfork makes the UX story dead simple for key generation and backup. Keyoxide makes key discovery and trust bootstrapping dramatically easier as well.
As far as those with cryptography engineering experience that see it as useful... I mean I have designed the backend key management systems and hardware security modules for several large financial institutions and hundreds of billions of dollars of infrastructure, and have worked closely with many cryptographers who review our work, and the supply chain security engineers responsible for signing commits, packages, and reproducible builds for major linux distributions including the one I founded.
All of the above relies on PGP smartcards for signed commits, commit pushes, ssh, signed reviews, trust bootstrapping, because no other tooling or spec has that covered with multiple competing implementations to choose from as well as PGP.
The only fair point in the article still relevant today IMO is forward secrecy but any tooling that really needs that like an instant messenger would use ciphers and protocals designed for that. PGP would just be used as an identity CA to bootstrap trust in those cases if anything.
I've done similar work and would not describe myself as a cryptography engineer, just a systems person with a security specialization. (I've been pretty consistent about this point on HN, this isn't just something I'm saying because it's convenient for the thread).
When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing.
How do you respond to the PGP format points raised in that post? How do you respond to the prevalence of the MDC construction?
> When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing.
I am not going to drag anyone else or their reputations into this conversation but they can chime in if they want to.
The general vibe I get about PGP among the cryptography engineers in my universe, that I share, is that it is an awkward spec that would have never been designed today, and has a lot of legacy ciphers that should never be used anymore that modern tooling must not expose, etc. But also, that re-inventing very widely used and established standards and tools that are secure enough for those use cases is rarely worth it.
PGP is the bootstrap trust layer for the internet, governments, linux distros, and critical infrastructure all over the world and it is not going away, so might as well take advantage of the compatibility wins of modernizing it.
We would have designed HTTP and TLS and the internet as a whole a -lot- differently today too. They are broken as hell but the job is to improve and upgrade even when it would be more fun to start over. In hindsight, everything is shit. But I am not about to try to make a new internet and convince people to use it. That is more complex to do than living with and working around the early dumb design choices when they can be made secure.
We do not just abandon HTTP and TLS, we navigate early awkward choices and we debate and iterate on new versions of standards. Similarly, many teams including mine, put in the work to modernize PGP tooling, and the OpenPGP working group still exists and still iterates on the standard (Though admittedly not as much as many of us would like).
It is my general opinion that for all the faults of PGP, it is still the best personal cryptographic identity anchored encryption and signing solution we have, especially when combined with smartcards and keyoxide. From there a rich ecosystem of tooling builds on top of that.
PGP (with modern tooling and ciphers) is much more sensible to recommend overa fragmented set of one trick tools with no key discovery, validation, or backup strategy that are bound to leave users with lost, stolen, or impersonated keys.
Anyways, at this point my feeling is that you've essentially conceded the actual point I was making (that PGP is itself also a shitshow of 1990s cryptography), and answered that you just don't care that it is. That's a perfectly coherent point to make and not one I'm super interested in litigating today.
I have only read that single post by that author and it passed my logic smoke test on a first pass. I am not commenting on any other work by that author and this seems like an ad hominem argument rather than refuting any content of that article.
Also I never actually disagreed that PGP as a specification, has a lot of 1990s holdovers given its history and age. Thankfully we have modern tooling now with reasonably secure defaults.
I was mostly arguing against the article you shared whose conclusions I absolutely disagree with.
IMO OpenPGP, however aged the spec design, when used with modern tools in turn using the unified smartcard interfaces, is still a way better choice than a hodge podge of ssh keys, minisign, age, openssl, etc without any standardized solutions for key revocation, rotation, backup, discovery, verification, etc.
This has been a mostly unproductive thread that has done a good job of avoiding the point of my original comment, which is that the archaisms in PGP are not merely a consequence of the GnuPG implementation, but also deeply embedded into the standard itself. I don't care if you feel like PGP is still a worthy tool (I don't think it is, but I get that we can go back and forth on that). You made (by implication) a false claim, and it was false in an important way, and it has now been falsified.
I have made no false claims or implications that I am aware of.
Mainly I was arguing at your implication that PGP is the wrong tool for any job as your link concluded.
I don't doubt you or a lot of people could build something better, but nobody has yet, and I doubt any will get it as widely adopted and supported end to end for all the use cases PGP is used for today. PGP is here to stay, and thus must be maintained and improved.
I don't see bike shedding about things that could have been done better historically in the spec itself as productive as there are no significant security problems with any of the active uses of PGP I use or am aware of in wide use today, if done with modern tools and with modern cipher defaults.
I would not recommend generating keys with GnuPG today any more than I would recommend using Internet Explorer. Advising against old broken implementations is not the same thing as saying we should abandon an established widely used cryptographic identity standard for which no comparable alternatives exist. Especially when alternative tooling with reasonable secure defaults exists now.
I doubt this discussion was productive for you or me, but hopefully it will be productive for others reading trying to make sense of their choices and tradeoffs.
I do appreciate people like you keeping me honest on this stuff regardless.
I believe lrvick said that the spec isn't perfect but works fine in practice, and advises against old broken implementations of it. We will see. In any case, imperfection does not imply fundamental flaw.
I might have missed it. Have you elaborated on why you think OpenPGP is fundamentally flawed? Do you know of any GPG replacements (or rather, OpenPGP replacements)? I want encryption, signing, key management, email integration (optional), multiple recipients, subkeys, revocation certificates, web of trust (even if unused), smart card support, and so on.
"Works fine in practice" is not responsive to "outmoded fundamentally, not just by one implementation". That commenter is substituting their own rooting interest in a particular outcome with a straightforward descriptive claim about the standard.
I will not, because I joined this subthread to make a specific point (that the other commenter was simply wrong that the archaisms in PGP/OpenPGP are a mere consequence of GnuPG and avoidable by avoiding GnuPG), and this whole subthread has been an exercise in avoiding that point and switching to other more tractable arguments. I'm sorry, but I'm not interested.
Not having gpg-agent is a huge deal breaker for me. I feel gpg-agent doesn't get enough love. Not only can it do all the ssh-agent operations, it can also be used with gpgme-json[1] to do web authentication with your [A] key. It's truly a shame that hardly any applications leverage the powerful cryptography afforded by GPG.
What do you mean? I use GPG with SSH (or SSH with GPG) all the time, and I need gpg-agent for that. GPG's agent replaces ssh-agent and serves SSH keys derived from your GPG key.
Can you do this with Age? If not, then I am going to stick to GPG.
Oh well, let us just agree on that comparing Age to GPG is silly, ergo "Switching from GPG to Age" is silly, unless it is "Switching from GPG to Age for file encryption".
Age doesn't do signing, key infrastructure, or email. Minisign/signify only sign. None are GPG replacements. They're partial feature subsets that are simpler because they do less.
So, to summarize these tools:
- Age: Only does file encryption, no signing, no key management infrastructure, no email integration
- Minisign/Signify: Only signing, no encryption
- GPG: Encryption, signing, key management, email integration, multiple recipients, subkeys, revocation certificates, web of trust (even if unused), smart card support, etc.
You cannot just simply switch from GPG to Age unless you are only doing file encryption. If this is the case, then sure, you can.
But I don’t think it will ever be a replacement for gpg (and might have already passed its window to replace it for file encryption). It just does file encryption. GPG does tons of other things that you will find are very useful (like around key management and signatures).
Literally the only thing I ever actually used gpg for was file encryption. I tried dong key management and signatures for a very brief period 20 years ago and gave up because no one else was doing it and it was annoying trying to do the right opsec things with no payoff.
Ever since then, as far as I can tell there has been a very small very niche group who use gpg for anything other than file encryption. So age is the obvious choice for the vast majority of us and it's adoption seems to be reflecting that.
By very small niche group, you mean every maintainer of every widely used production linux distribution and most of the core packages that form the supply train trust layer for the entire internet? Or every reasonably competent security vulnerability disclosure team? (Even Google and Apple!)
PGP is the only standardized cryptographic online identity layer we have and still very heavily used by anyone working on security critical software for signed commits, signed reviews, system administration, etc.
Honestly I find it hard to take anyone seriously who works in any engineering role where security matters that is -not- using PGP smartcards to sign and push their commits, sign code reviews, sign build reproductions of container images, encrypt their passwords, etc.
Yes. That they have a large impact does not change the fact that not I nor anyone in my close circle uses it for that. It has been relegated to a specialized domain and use case. I have no use for maintaining a signing key. All the communications I need to secure and verify identity use a different technology for it. The fact that some tools I run might use it in the background is entirely abstracted away for me and they could get swapped by something else without me once noticing.
If you write open source code others rely on, or have any online identity that could be used for harm if stolen, it is irresponsible to not have a well published public identity signing key that cryptographically ties together your online presences to make you hard to impersonate. A key used to sign commits, binaries, code reviews, emails, or anything else of public value you produce.
If you do not do anything of consequence outside of corporate walls and are just a passive consumer of technology, then you probably do not need one.
The fact you have keybase in your profile indicates to me that you at least at one point mildly cared about having a cryptographic identity. Keybase just happened to have been a wildly broken implementation. Keyoxide is the path today.
Thank you for your comment. For a minute I thought I was going insane because there is no way that GPG/PGP is used only by the minority. Literally everyone uses it, even non-techies.
phew
> any engineering role where security matters that is -not- using PGP smartcards to sign and push their commits, sign code reviews, sign build reproductions of container images, encrypt their passwords, etc.
I agree. Even without smartcards, at the very least sign your commits, among other things. Absolute minimum. Very low bar.
Every time I get a dev or executive sending me a Slack message saying "can you reset my password" or "can your provision me in...", my very next reply is "please send me your public key".
They do not get their credentials until they do so. And once they do, our security posture gets better and better.
As for how it improves security, I'm going to hazard a guess that many of the people sending zikduruqe those messages hadn't previously set up a PGP key. So by asking for the public key and refusing to send them the credentials until he receives it, he's forcing them to set one up, which then makes it possible for them to do things like sign messages. Just making someone set up a keypair doesn't mean they'll use it correctly, but it's hard to argue against the idea that a company's security posture is improved when more people have PGP keys.
It’s so easy to use insecurely that I will argue that employees setting up PGP keys and then potentially trying to use them does weaken the company’s security posture.
I agree it is easy for people to shoot themselves in the foot with many historcal PGP tools, which is exactly why we made keyfork.
It generates modern ECC PGP keychains with best practices in one shot, with multiple reasonably secure user friendly paper or smartcard, backup solutions.
You will really know what you are doing to force keyfork to generate an unsafe keychain. Especially if you use it on AirgapOS, which ships with it.
Care to elaborate on this? How come using PGP insecurely is somehow more insecure than not using it at all? And what do you exactly mean by using it insecurely? Care to give me an example of this insecure use of PGP?
Asking for their public key lets you encrypt messages that only their private key can decrypt, and verify signatures they create. It doesn't by itself prove their real identity, you still need to verify the key's authenticity (e.g. via fingerprint comparison or a trusted keyserver) to avoid impersonation or man-in-the-middle attacks.
I think what I’ve gathered is that the person I replied to is going with a TOFU model of key security (trust on first use), or is just seeking to avoid plaintext passwords in slack messages and is treating the key as disposable for the one-time encryption of the password.
Presumably they must trust that the user messaging them on slack is indeed who they say they are and is in control of the account.
If I’ve understood correctly, this seems like one of those cases where PGP is adding quite little security to the system, and may be preventing the implementation of more secure systems if it is providing a false sense of security.
But it’s probably just someone doing their best in a system beyond their control.
Like I have said in another comment, the question of identity verification makes no sense in this context. The identity verification problem is orthogonal to the encryption scheme.
That is an extremely weird argument. They aren't separable concerns. If you have a trusted identity in place you could use a password-protected AES ZIP file for all the encryption matters.
> I think I'm missing something, how does asking for their public key improve security or verify their identity?
OK, so this was the question. My response should have been "it does not necessarily verify their identity". I mentioned some of the mechanisms for identity verification in the other thread.
It allows the security guy (in this case, zikduruqe) to send an email that can only be read by the person who possesses the corresponding private key. Which means that either the email is going to the executive who really does own the account, or else that the attacker has already breached that executive's laptop to the point of having acquired his private key (and passphrase, if there was one), in which case phishing attempts to get a password would be utterly pointless (like trying to pick the lock of the front door when you're already inside the house).
Well, I've been assuming that zikduruqe is competent and knows how to pick up a phone and call the person (looking up a phone number in the company database) to verify that the public key came from him via fingerprint-checking over the phone. Sometimes people leave steps out so as not to write essays in a comment box.
My confusion here is that if you're doing that, why bother with the cryptography? You can just look the person up in the company database, call them, and say "Hey! Did you just request a password reset?".
If one of your pre-requisites is "There is a trusted out-of-band way for me to validate comms with this person", the crypto is just extra bits.
The question makes no sense in this context. The identity verification problem is orthogonal to the encryption scheme.
This problem exists regardless of PGP. If someone's Slack is compromised:
With PGP: attacker gets credentials encrypted to their key
Without PGP: attacker gets plaintext credentials
But both fail at the same point: verifying who you're talking to. That's not a PGP problem, it's a "doing password resets over unauthenticated Slack" problem.
PGP does provide multiple identity verification mechanisms, e.g. web of trust, key signing, fingerprint verification, in-person key exchange, and Keybase-style social proofs linking keys to verified accounts.
The workflow described just doesn't use them. Identity verification is required for ANY secure credential exchange system; you either verify keys properly (signed by trusted parties, verified fingerprints, pre-enrolled, social proofs) or you have the same problem with passwords, TOFU SSH keys, or anything else.
Are you criticizing PGP for not solving a problem that the workflow simply didn't implement a solution for?
That's only true if the key's authenticity isn't verified. If you just accept any key a person gives you, then yes, it's meaningless. But if you independently confirm the key's fingerprint through a trusted channel, it becomes a real security measure that prevents impersonation and ensures confidentiality.
The workflow as described (no verification step) is theater. But that's true for any credential exchange without identity verification, PGP or otherwise. The issue isn't PGP, it's skipping the verification step. PGP provides the tools (fingerprint verification, web of trust, key signing), but you have to actually use them.
The out-of-band verification is for initial key enrollment, not every credential exchange. You verify the fingerprint once through a trusted channel, then use that verified key indefinitely without needing the trusted channel again. That's the entire value proposition: establish trust once, communicate securely many times.
Without this, you'd need out-of-band verification for every single credential exchange, which doesn't scale.
As for "PGP is trash"... That's a different argument entirely, and you've provided zero technical justification for it. If you have specific criticisms of PGP's cryptographic primitives, key management model, or implementation security, make them.
I design most corporate bug bounty programs the same way.
Sure, people rarely use PGP, but the ones that do are usually serious and high quality, and we let them skip the tier 1 queue. Script kiddies never know how to encrypt things.
It has not at all been my experience that PGP-encrypted bounty submissions are fast-tracked and most (almost all, in fact) good bounty submissions aren't encrypted. Google downplays PGP in the link you provided. Apple doesn't ask people to use theirs.
It is provided as an option, the ONLY option, for those that feel encryption is merited for a sensitive report.
Google page: "If you feel the need, please use our PGP public key to encrypt your communications with us."
Apple page: "Apple security advisories are signed with the Apple Product Security PGP key. Sensitive security information may be encrypted to this key when communicating with Apple Product Security."
"Sensitive enough" is smuggling in a presumption of yours that isn't supported by evidence. Whether or not submissions are PGP-encrypted (in my experience: they very rarely are) is uncorrelated with their severity.
In my experience building bug bounty programs for many high risk orgs, PGP reports are rare, as you indicate. Maybe a couple a year.
That does not make them any less critical or relied on. We always took them super seriously and read them offline because they were often highly sensitive real disclosures that merited being exposed only to a very small circle of people with security team decryption smartcards.
It is a safe assumption skiddies do not know how to use PGP so low skill reports with PGP almost never happened.
I would never run a bug bounty program without having an highly visible public key to encrypt highly sensitive reports to.
You haven't responded to my point. I would happily run a bounty program without a PGP key; in fact, I'd recommend not publishing a PGP key, and instead making arrangements to communicate a Signal identity.
Repeating a comment elsewhere on the thread so I'll keep this very brief, but it is in fact bad that PGP "does tons of other things that you will find are very useful".
age is so clean precisely because it does only one thing.
While GPG has other use cases; the intent is that those use cases are satisfied by different tools. Eg: signify for signing.
I’m also considering moving away from GPG, but the main limitation are signed git tags (for releases). For supports GPG or SSH keys. I’m not sure that I’m a fan of signing with SSH keys, I’d rather have first-class support for signify.
> I'm now experimenting with `age`, which touts itself as "simple, modern, and secure encryption". If needed, I will use `minisign` for signatures.
I have also switched from GPG to age.
When I wanted to start signing my open-source software releases because of recent supply-chain attacks, I first thought of Minisign, too.
I tried it for binaries and even found a few third-party Git integrations (https://codeberg.org/SkyFox42/git-minisign, https://github.com/sug0/git-signify), then discovered that Git and GitHub supported signing with SSH keys (https://stackoverflow.com/questions/72844616).
GitHub supports it in the sense that it will indicate a commit or tag is signed.
I have adopted this approach: I sign tags with `git tag -s foo` and binaries with `ssh-keygen -Y sign`, and I have put the public key and usage instructions on my site (https://dbohdan.com/pubkeys).
No.
age developer Filippo Valsorda has experimented with Kyber/ML-KEM and maintains a Go library for it, https://github.com/FiloSottile/mlkem768.
The public key size is intimidating.
Age only covers encryption. It does not cover signing, ssh, web of trust, hierarchical keys, key discovery, etc. It is in no way a replacement for a modern PGP keychain.
Ignore GnuPG which is a shit show stuck in the 90s. PGP != GPG
For a modern long lived personal PGP keychain use Keyfork on AirgapOS which gives you a secure 24 word mnemonic backup, optional split backup across redundant smartcards, and a separation of a CA key and daily driver subkeys on smartcards all done correctly so you do not have to think about it. I would suggest a Nitrokey Pro due to open source rust firmware, though Yubikeys are supported.
From there you can use your smartcard for ssh, password management, git commit signing, etc. and make your key easy to discover without impersonation using keyoxide to have all your services, domains, etc attest to your key, as well as any humans who vouch for you.
A proper PGP keychain is a long lived digital passport first, that has encryption and authentication subkeys.
https://git.distrust.co/public/keyfork
https://git.distrust.co/public/airgap
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.
Even if you ONLY care about encrypting files presumably you want to be able to decrypt them far into the future, with confidence no one else can do so.
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.
age has Yubikey support. The idea that the PGP ecosystem "has you covered" on all these points is a bold claim. Certainly people talk about all these things, but when that system is put to the test, it rarely holds up. See for instance the keyserver fiasco.
Barely. Age has Yubikey support with no reasonable long term key discovery, backup, or rotation strategy as far as I can tell. All things modern PGP tooling supports.
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.
Just so I understand, you believe that age’s developer hasn’t thought enough about how to design cryptographic systems or tools?
I think even brilliant cryptographers can be wrong, or acting on strong biases formed from a limited perspective. In this case I think they have not thought about personal cryptographic key management and how people use tools like PGP in the wild well enough.
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.
I think Filippo Valsorda has in fact thought pretty hard about the issues you're talking about, and that, by contrast, the track record of the PGP community on those same issues is pretty dismal.
I think the tldr of their point is that Filippo thought a lot about cryptography but not about actual users or their requirements. What he thinks are cruft are actual features that users depend on
No, I got the tldr of their point just fine. They're just wrong.
If I am wrong I challenge you to point at a well specified replacement for PGP with a diversity of competing implementations as a decentralized cryptographic identity and trust system for open source software supply chain signing, authentication, and peer to peer encryption with a variety of smartcard generation, usage, and backup solutions better for every situation PGP is used in today.
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.
I'm not the one insulting Filippo Valsorda, for no apparent reason (any of your points could have been made without criticizing him), when he's not present to defend himself in this thread. The onus is squarely on you here. You won't succeed, though, so I don't blame you for not wasting the time.
It’s unclear to me any stateful keychains are implied here. The decrypting system has N number of keys available. It tries to authenticate the ciphertext with those N keys. If the ciphertext authenticates, then return the decrypted cleartext.
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...
> It’s unclear to me any stateful keychains are implied here.
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.
> but still there is a long lived secret a user must maintain somewhere
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.
Wait, how does minisign "pretend the problems PGP solves do not exist"? Minisign is an example of a purpose-built tool designed specifically to address a problem PGP attempts to solve. We're now talking about two different tools each of which addresses something in PGP's scope. If we keep fleshing out PGP's scope, we'll keep finding more tools like this, because very few people operationalize PGP and lots of people have the problems PGP attempts to solve.
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.
Minisign and Age entirely dodge the actually hardest problem with humans using cryptography, that PGP puts front and center: identity and public key discovery. You cannot just skip these!
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.
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.
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.
ssh covers ssh and now signing, eg for git commits. The vouching and web of trust stuff never worked for mist people.
Abusing ssh for signing is a silly thing to do in most cases when modern PGP tooling covers this and so many other use cases with established standards.
Also, again, use keyoxide which is a modern decentralized alternative to keybase. You can vouch for yourself to bootstrap trust.
Why do you call it abuse?
OpenSSH keys were only meant for signing OpenSSH connection handshakes. They were meant for authentication, not signing long lived data. This is why PGP has distinct authentication and signing subkey types which can have different policies and permissions.
Using ssh authentication keys to also sign software is a total hack, and worse, means you are now using a single key for multiple distinct use cases without a subkey system, CA, or rotation strategy, or the ability to revoke a key for one use case without compromising others or forcing a full keychan rotation.
Telling people to use a single private keypair for many unrelated use cases has always been short-sighted cryptography advice and still is.
I get that gpg UX is remarkably bad and makes everyone want to run screaming from PGP, but modern tooling exists now and for all the things the PGP spec got wrong, it got a lot more right.
Watching new solutions get wrong the few things PGP got right as an answer to PGP is kind of infuriating.
All the docs encourage you to use a different ssh key for signing I think; certainly I do.
There are not many reasons for signing without a strategy for key discovery and verification so others can verify your signatures are really yours and not that of an imposter.
SSH Authenticaton subkeys are widely shared publicly on every git host I am aware of. If you use a separate key for signing than you use for authentication, then you throw away the only established SSH key discovery method.
Now you solved the overloaded key problem, while making key discovery worse.
Everyone seems to be trying to re-solve problems with ssh keys that PGP actually solved reasonably well.
I'm only familiar with GitHub, but signing keys are kept entirely separate from authentication keys, and must be uploaded separately.
A GitHub user's signing keys are available at a different API endpoint:
https://api.github.com/users/username/ssh_signing_keys
https://docs.github.com/en/rest/users/ssh-signing-keys?apiVe...
as opposed to the auth public keys, which are at:
https://github.com/username.keys
Isn't this more of a theoretical problem, rather than a practical one? In what situations do you want people to discover your key? You create a key pair for Github, upload the public key, and you're done; you can securely communicate with Github. Nobody ever has to discover it. Do they?
> In what situations do you want people to discover your key
Just to name some of the most common use cases I have:
1. When people in my orgs want to encrypt sensitive information to me, e.g in encrypted password databases over git.
2. When prospective new clients or security researchers want to encrypt sensitive requests to me via email. Have some in my inbox right now from today.
3. When people want to verify that commits or code reviews I signed on security critical software were really signed by me, and not masquerade malicious code as mine in a rebase, etc.
4. When people want to verify that public reproducible builds of artifacts I maintained are built by multiple maintainers.
These use cases all rely on a well published set of public keys shared with the public in ways with sufficient history and signatures so no one can impersonate me or other maintainers, or make it possible to easily trick people to encrypting data to keys that are not really ours.
I sign 100% of my commits, and 100% of all artifacts I maintain etc. Anyone claiming to be me on anything important without signatures from my very well established and easy to verify public keys, are not me.
A PGP key is the only standardized cryptographic passport for the internet and if you don't attach your work to an easily verifiable key you are one compromised account away from having your online identity used for supply chain attacks.
All major linux distributions and the core infrastructure on the internet is anchored in the PGP keys of few thousand people that put in the work to maintain well published keychains.
The only alternatives anyone have proposed are use Fulcio and let Google sign everything for you as a single point of failure for the internet. Hard pass.
Meanwhile with solutions like keyoxide, anyone can form confidence my key is mine trivially without relying on a central party:
https://keyoxide.org/6B61ECD76088748C70590D55E90A401336C8AAA...
> A PGP key is the only standardized cryptographic passport for the internet
I think this rather gives the game away.
For people for whom PGP is important, their PGP key is their identity. And there is a community of people like this. But it's small--I'd guesstimate maybe a million people or so at best, a true rounding error in terms of the internet.
For most people, however, their online identity is generally tied around one of a few core providers. The de facto identity for open source is GitHub, for better or worse. Do I like that we've moved to centralized identity management? Not particularly. But it is telling that in the shift towards identity management as a concept (e.g., OAuth2) in the past decade, PGP hasn't played a factor.
And in all of your passionate defenses of PGP, where you've complained that things don't support the PGP identity model, you've never really addressed the issues that a) most people don't have a PGP identity, b) PGP identity doesn't provide any practical value over existing identities, or c) things already work well enough with other identity models, that PGP identities don't integrate well with.
So just out of curiosity, what is this modern tooling? It was brought up previously in this thread without naming any names.
Just to name a few of the projects I work on, use, or find most interesting:
https://keyoxide.org/
https://git.distrust.co/public/keyfork
https://git.distrust.co/public/airgap
https://codeberg.org/heiko/openpgp-pkcs11
https://codeberg.org/openpgp-card/openpgp-card-tools
https://sequoia-pgp.org/
https://github.com/rpgp/rpgp
https://www.nitrokey.com/news/2021/new-nitrokey-3-nfc-usb-c-...
https://doc.qubes-os.org/en/latest/user/security-in-qubes/sp...
It's hard to know how these pieces fit together, especially if you have a fuzzy mental-model of the objectives and potential benefits. Is there a gentle introduction you'd recommend?
There are many ways to use PGP just as there are many ways to use openssl or any other cryptographic suite of tools.
For most individuals seeking to establish a long term durable personal keychain they want others to be able to externally trust and verify easily, I would suggest the following, which is more or less what most people in my circles do:
1. Buy a smartcard with touch support such as a Nitrokey 3
2. Ideally buy 3+ backup smartcards at the same time
3. Use Keyfork on AirgapOS booted on a laptop you trust to generate a 24 word mnemonic and split-encrypt it to 3+ smartcards (or write down mnemonic on paper if you lack budget for 3 extra smartcards)
4. If using backup smartcard set, split them up across 3 secure locations, or if using a raw mnemonic put on durable storage such as cryptosteel, and put that in tamper evident storage such as in a vacuum sealed bag with confetti with pictures you have copies of elsewhere.
5. Use keyfork to derive a PGP key and load it into your smartcard
6. Setup forced/locked "touch" requirement policies on all "slots" on your card so you must tap for each use (malware cannot do this, but easy for you to do)
7. Publish public key to keys.ogenpgp.org
8. Publish public key on your own domain name using Web Key Discovery
9. Use keyoxide docs to establish keyoxide profile with every internet platform you control attesting your key fingerprint is yours to make it easy for others form confidence that all of those are you, and your key is yours.
10. Major bonus: use QubesOS and map your smartcard only to an offline vault VM that prompts you for each use, and which security domain on your system wants to use your key, so malware is unlikely to be able to trick you even if your development environment is compromised.
From there you can use your provisioned smartcard with an openpgp smartcard capable ssh agent on your workstation for git signing, git push, ssh to servers, password management with password store, signing artifacts, thunderbird for email encryption, etc.
We plan on writing up a lot more public documentation for this sort of thing as the public docs suck, but we have helped thousands of people with this sort of thing.
Pop into #!:matrix.org or #keyfork:matrix.org if you want any help or advice for specific use cases.
A partially complete set of docs for different threat models is in progress at https://trove.distrust.co
There are many ways to use PGP just as there are many ways to use openssl or any other cryptographic suite of tools.
This is a very bad thing, because it is not in fact the case that there is one cryptosystem equally suited to all these tasks.
That you chose OpenSSL as your corroborating example is especially funny, because there is exactly one thing that OpenSSL is actually well-suited to doing (setting up TLS sessions), and then 20+ years of people getting themselves into grave trouble trying to get that library to do other things.
You spend a lot of energy steering people away from PGP, but what is your alternative to solve the same problems with the same threat models?
What do you want to shift the entire software supply chain security foundation of the internet to use instead and how?
Complaining the existing solution is not good enough is easy. Making things better and educating on current best efforts without creating centralized points of trust is hard.
Did you not read the post I linked upthread? You were quite confident in refuting its claims, so I assume we shared an understanding here.
Update
It looks like you drastically edited your comment after I replied to it, in ways that change the meaning of your prompt. That makes it impossible for us to continue discussing anything.
It’s not because WoT necessarily doesn’t work, but people simply don’t need to verify digital signatures. Whatever needs to be done is done internally by apps.
Dark web runs on PGP. People with no technical knowledge use it. Nobody has broken their communication. Not that this is a good use case, just saying bums can use PGP too!
The biggest use case is currently software signing. Like you would verify a master key for a project under TOFU model, once through several channels. From there, verifying software signed by keys signed ultimately by that master key is done easily and securely.
I like the idea of AirgapOS; "just turn off the network" has always felt a little dissatisfying.
That said, if you're already in the GnuPG ecosystem, https://incenp.org/notes/2015/using-an-offline-gnupg-master-... will cover you for pretty much everything here except the mnemonic backup using baseline tooling. I presume you can get a shell utility to pipe your key in and get that mnemonic version out if you'd like.
> I presume you can get a shell utility to pipe your key in and get that mnemonic version out if you'd like.
Not possible as GnuPG does not expose access to the cryptographic seed.
That said a mnemonic you generate and backup with keyfork is entirely compatible with GnuPG should you still want to use it as a client for keyfork-provisoned smartcards.
You can also use that same mnemonic to generate any other cryptographic keys you want for any purpose, including Age.
No, PGP is also a shit show stuck in the 1990s.
https://www.latacora.com/blog/2019/07/16/the-pgp-problem/
Keyfork only uses modern ECC PGP keys supported by the spec, prioritizing smartcard use, and using BIP32 KDF from a 256 bit mnemonic seed.
Nothing else comes close to the broad compatibility PGP offers. Just need to ignore legacy ciphers.
I suggest looking at the links. Latacoras take on this is IMO wildly out of date (6 years old to be fair).
PGP powers the core software supply chain security trust layer for the Linux distributions and tooling that power the whole internet and the standard does get updated.
PGP is not going away, but it is being upgraded.
The post covers this (not Keyfork itself, but Sequoia, on which Keyfork appears to depend).
Sequoia is only used as a library for a few crypto primitives that there are multiple alternatives for now we will be switching to.
Thankully, because of standards, we can switch to a leaner library set without breaking compatibility.
https://codeberg.org/heiko/pkcs11-openpgp-notes
I think you should read the post. It's mostly not about things implementations can improve about the PGP ecosystem on their own.
Then, I think you should talk to professional cryptography engineers. I'd be interested if you could find even one who believes the PGP ecosystem should be kept going. My distaste for PGP is not an idiosyncrasy; it's something I learned from cryptographers, who fucking hate PGP.
I read it when it was first posted and my team and I have personally done a lot to address some of the more fair points like UX. Keyfork makes the UX story dead simple for key generation and backup. Keyoxide makes key discovery and trust bootstrapping dramatically easier as well.
As far as those with cryptography engineering experience that see it as useful... I mean I have designed the backend key management systems and hardware security modules for several large financial institutions and hundreds of billions of dollars of infrastructure, and have worked closely with many cryptographers who review our work, and the supply chain security engineers responsible for signing commits, packages, and reproducible builds for major linux distributions including the one I founded.
All of the above relies on PGP smartcards for signed commits, commit pushes, ssh, signed reviews, trust bootstrapping, because no other tooling or spec has that covered with multiple competing implementations to choose from as well as PGP.
The only fair point in the article still relevant today IMO is forward secrecy but any tooling that really needs that like an instant messenger would use ciphers and protocals designed for that. PGP would just be used as an identity CA to bootstrap trust in those cases if anything.
I've done similar work and would not describe myself as a cryptography engineer, just a systems person with a security specialization. (I've been pretty consistent about this point on HN, this isn't just something I'm saying because it's convenient for the thread).
When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing.
How do you respond to the PGP format points raised in that post? How do you respond to the prevalence of the MDC construction?
> When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing.
I am not going to drag anyone else or their reputations into this conversation but they can chime in if they want to.
The general vibe I get about PGP among the cryptography engineers in my universe, that I share, is that it is an awkward spec that would have never been designed today, and has a lot of legacy ciphers that should never be used anymore that modern tooling must not expose, etc. But also, that re-inventing very widely used and established standards and tools that are secure enough for those use cases is rarely worth it.
PGP is the bootstrap trust layer for the internet, governments, linux distros, and critical infrastructure all over the world and it is not going away, so might as well take advantage of the compatibility wins of modernizing it.
We would have designed HTTP and TLS and the internet as a whole a -lot- differently today too. They are broken as hell but the job is to improve and upgrade even when it would be more fun to start over. In hindsight, everything is shit. But I am not about to try to make a new internet and convince people to use it. That is more complex to do than living with and working around the early dumb design choices when they can be made secure.
We do not just abandon HTTP and TLS, we navigate early awkward choices and we debate and iterate on new versions of standards. Similarly, many teams including mine, put in the work to modernize PGP tooling, and the OpenPGP working group still exists and still iterates on the standard (Though admittedly not as much as many of us would like).
As for MDC, another thing that is awkward, but good enough: https://articles.59.ca/doku.php?id=pgpfan:mdc
It is my general opinion that for all the faults of PGP, it is still the best personal cryptographic identity anchored encryption and signing solution we have, especially when combined with smartcards and keyoxide. From there a rich ecosystem of tooling builds on top of that.
PGP (with modern tooling and ciphers) is much more sensible to recommend overa fragmented set of one trick tools with no key discovery, validation, or backup strategy that are bound to leave users with lost, stolen, or impersonated keys.
Are you sure you want to be citing that particular site to defend the MDC? Do you co-sign other things it says?
https://articles.59.ca/doku.php?id=pgpfan:index
Anyways, at this point my feeling is that you've essentially conceded the actual point I was making (that PGP is itself also a shitshow of 1990s cryptography), and answered that you just don't care that it is. That's a perfectly coherent point to make and not one I'm super interested in litigating today.
I have only read that single post by that author and it passed my logic smoke test on a first pass. I am not commenting on any other work by that author and this seems like an ad hominem argument rather than refuting any content of that article.
Also I never actually disagreed that PGP as a specification, has a lot of 1990s holdovers given its history and age. Thankfully we have modern tooling now with reasonably secure defaults.
I was mostly arguing against the article you shared whose conclusions I absolutely disagree with.
IMO OpenPGP, however aged the spec design, when used with modern tools in turn using the unified smartcard interfaces, is still a way better choice than a hodge podge of ssh keys, minisign, age, openssl, etc without any standardized solutions for key revocation, rotation, backup, discovery, verification, etc.
This has been a mostly unproductive thread that has done a good job of avoiding the point of my original comment, which is that the archaisms in PGP are not merely a consequence of the GnuPG implementation, but also deeply embedded into the standard itself. I don't care if you feel like PGP is still a worthy tool (I don't think it is, but I get that we can go back and forth on that). You made (by implication) a false claim, and it was false in an important way, and it has now been falsified.
I have made no false claims or implications that I am aware of.
Mainly I was arguing at your implication that PGP is the wrong tool for any job as your link concluded.
I don't doubt you or a lot of people could build something better, but nobody has yet, and I doubt any will get it as widely adopted and supported end to end for all the use cases PGP is used for today. PGP is here to stay, and thus must be maintained and improved.
I don't see bike shedding about things that could have been done better historically in the spec itself as productive as there are no significant security problems with any of the active uses of PGP I use or am aware of in wide use today, if done with modern tools and with modern cipher defaults.
I would not recommend generating keys with GnuPG today any more than I would recommend using Internet Explorer. Advising against old broken implementations is not the same thing as saying we should abandon an established widely used cryptographic identity standard for which no comparable alternatives exist. Especially when alternative tooling with reasonable secure defaults exists now.
I doubt this discussion was productive for you or me, but hopefully it will be productive for others reading trying to make sense of their choices and tradeoffs.
I do appreciate people like you keeping me honest on this stuff regardless.
> I would not recommend generating keys with GnuPG today any more than I would recommend using Internet Explorer.
Would you rather recommend Sequoia-PGP or what?
"Nobody has built something better" is not responsive to the argument that "PGP is fundamentally outmoded, not just one implementation of it".
Are you arguing that OpenPGP itself is fundamentally flawed, or only GnuPG (which is one implementation of OpenPGP, Sequoia is another)?
That OpenPGP itself is fundamentally flawed (it clearly is, and my interlocutor here has conceded that.)
I believe lrvick said that the spec isn't perfect but works fine in practice, and advises against old broken implementations of it. We will see. In any case, imperfection does not imply fundamental flaw.
I might have missed it. Have you elaborated on why you think OpenPGP is fundamentally flawed? Do you know of any GPG replacements (or rather, OpenPGP replacements)? I want encryption, signing, key management, email integration (optional), multiple recipients, subkeys, revocation certificates, web of trust (even if unused), smart card support, and so on.
"Works fine in practice" is not responsive to "outmoded fundamentally, not just by one implementation". That commenter is substituting their own rooting interest in a particular outcome with a straightforward descriptive claim about the standard.
I would appreciate it if you answered to the rest of my comment. It may be quite useful.
I will not, because I joined this subthread to make a specific point (that the other commenter was simply wrong that the archaisms in PGP/OpenPGP are a mere consequence of GnuPG and avoidable by avoiding GnuPG), and this whole subthread has been an exercise in avoiding that point and switching to other more tractable arguments. I'm sorry, but I'm not interested.
Not having gpg-agent is a huge deal breaker for me. I feel gpg-agent doesn't get enough love. Not only can it do all the ssh-agent operations, it can also be used with gpgme-json[1] to do web authentication with your [A] key. It's truly a shame that hardly any applications leverage the powerful cryptography afforded by GPG.
[1]: https://manpages.debian.org/trixie/gpgme-json/gpgme-json.1.e...
I knew about gpgme-json, but I didn't knew, you could do web auth with that. I though the usecase was mainly mailvelope. How does that work?
I want to know as well, I just read gpgme-json page posted, but it doesn't include anything about WebAuthn (aka passkeys).
Can you use GPG-agent for non-resident passkey challenges?
I also have Yubikey setup, but haven't thought of this.
> Not only can it do all the ssh-agent operations
It can not. Doesn't work with PKCS#11 PIV. In general GPG's behavior with SmartCards is idiotic and interferes with many other applications.
It's good that people don't use GPG more often and I can just purge it from my systems.
What do you mean? I use GPG with SSH (or SSH with GPG) all the time, and I need gpg-agent for that. GPG's agent replaces ssh-agent and serves SSH keys derived from your GPG key.
Can you do this with Age? If not, then I am going to stick to GPG.
I'm unsure what was unclear. It simply does not provide PIV support and it interferes with other software that wants to utilise SmartCards.
Can Age interfere with all SmartCard usage? No clue.
Oh well, let us just agree on that comparing Age to GPG is silly, ergo "Switching from GPG to Age" is silly, unless it is "Switching from GPG to Age for file encryption".
Age doesn't do signing, key infrastructure, or email. Minisign/signify only sign. None are GPG replacements. They're partial feature subsets that are simpler because they do less.
So, to summarize these tools:
- Age: Only does file encryption, no signing, no key management infrastructure, no email integration
- Minisign/Signify: Only signing, no encryption
- GPG: Encryption, signing, key management, email integration, multiple recipients, subkeys, revocation certificates, web of trust (even if unused), smart card support, etc.
You cannot just simply switch from GPG to Age unless you are only doing file encryption. If this is the case, then sure, you can.
Age is super clean and very nice.
But I don’t think it will ever be a replacement for gpg (and might have already passed its window to replace it for file encryption). It just does file encryption. GPG does tons of other things that you will find are very useful (like around key management and signatures).
Literally the only thing I ever actually used gpg for was file encryption. I tried dong key management and signatures for a very brief period 20 years ago and gave up because no one else was doing it and it was annoying trying to do the right opsec things with no payoff.
Ever since then, as far as I can tell there has been a very small very niche group who use gpg for anything other than file encryption. So age is the obvious choice for the vast majority of us and it's adoption seems to be reflecting that.
By very small niche group, you mean every maintainer of every widely used production linux distribution and most of the core packages that form the supply train trust layer for the entire internet? Or every reasonably competent security vulnerability disclosure team? (Even Google and Apple!)
PGP is the only standardized cryptographic online identity layer we have and still very heavily used by anyone working on security critical software for signed commits, signed reviews, system administration, etc.
Honestly I find it hard to take anyone seriously who works in any engineering role where security matters that is -not- using PGP smartcards to sign and push their commits, sign code reviews, sign build reproductions of container images, encrypt their passwords, etc.
Yes. That they have a large impact does not change the fact that not I nor anyone in my close circle uses it for that. It has been relegated to a specialized domain and use case. I have no use for maintaining a signing key. All the communications I need to secure and verify identity use a different technology for it. The fact that some tools I run might use it in the background is entirely abstracted away for me and they could get swapped by something else without me once noticing.
My point still stands.
If you write open source code others rely on, or have any online identity that could be used for harm if stolen, it is irresponsible to not have a well published public identity signing key that cryptographically ties together your online presences to make you hard to impersonate. A key used to sign commits, binaries, code reviews, emails, or anything else of public value you produce.
If you do not do anything of consequence outside of corporate walls and are just a passive consumer of technology, then you probably do not need one.
The fact you have keybase in your profile indicates to me that you at least at one point mildly cared about having a cryptographic identity. Keybase just happened to have been a wildly broken implementation. Keyoxide is the path today.
Except that I do all of those things and I don't care about it at all nor does the absence affect me in any way. Keybase was a nifty chat.
Thank you for your comment. For a minute I thought I was going insane because there is no way that GPG/PGP is used only by the minority. Literally everyone uses it, even non-techies.
phew
> any engineering role where security matters that is -not- using PGP smartcards to sign and push their commits, sign code reviews, sign build reproductions of container images, encrypt their passwords, etc.
I agree. Even without smartcards, at the very least sign your commits, among other things. Absolute minimum. Very low bar.
Every time I get a dev or executive sending me a Slack message saying "can you reset my password" or "can your provision me in...", my very next reply is "please send me your public key".
They do not get their credentials until they do so. And once they do, our security posture gets better and better.
I think I'm missing something, how does asking for their public key improve security or verify their identity?
As for how it improves security, I'm going to hazard a guess that many of the people sending zikduruqe those messages hadn't previously set up a PGP key. So by asking for the public key and refusing to send them the credentials until he receives it, he's forcing them to set one up, which then makes it possible for them to do things like sign messages. Just making someone set up a keypair doesn't mean they'll use it correctly, but it's hard to argue against the idea that a company's security posture is improved when more people have PGP keys.
It’s so easy to use insecurely that I will argue that employees setting up PGP keys and then potentially trying to use them does weaken the company’s security posture.
I agree it is easy for people to shoot themselves in the foot with many historcal PGP tools, which is exactly why we made keyfork.
It generates modern ECC PGP keychains with best practices in one shot, with multiple reasonably secure user friendly paper or smartcard, backup solutions.
You will really know what you are doing to force keyfork to generate an unsafe keychain. Especially if you use it on AirgapOS, which ships with it.
Care to elaborate on this? How come using PGP insecurely is somehow more insecure than not using it at all? And what do you exactly mean by using it insecurely? Care to give me an example of this insecure use of PGP?
Asking for their public key lets you encrypt messages that only their private key can decrypt, and verify signatures they create. It doesn't by itself prove their real identity, you still need to verify the key's authenticity (e.g. via fingerprint comparison or a trusted keyserver) to avoid impersonation or man-in-the-middle attacks.
He's asking how this procedure learns which public keys are trustworthy, not how asymmetric cryptography works.
I think what I’ve gathered is that the person I replied to is going with a TOFU model of key security (trust on first use), or is just seeking to avoid plaintext passwords in slack messages and is treating the key as disposable for the one-time encryption of the password.
Presumably they must trust that the user messaging them on slack is indeed who they say they are and is in control of the account.
If I’ve understood correctly, this seems like one of those cases where PGP is adding quite little security to the system, and may be preventing the implementation of more secure systems if it is providing a false sense of security.
But it’s probably just someone doing their best in a system beyond their control.
Like I have said in another comment, the question of identity verification makes no sense in this context. The identity verification problem is orthogonal to the encryption scheme.
See: https://news.ycombinator.com/item?id=45919561
That is an extremely weird argument. They aren't separable concerns. If you have a trusted identity in place you could use a password-protected AES ZIP file for all the encryption matters.
There are too many threads, see: https://news.ycombinator.com/item?id=45919651. I don't see why we got here from PGP though.
> I think I'm missing something, how does asking for their public key improve security or verify their identity?
OK, so this was the question. My response should have been "it does not necessarily verify their identity". I mentioned some of the mechanisms for identity verification in the other thread.
It allows the security guy (in this case, zikduruqe) to send an email that can only be read by the person who possesses the corresponding private key. Which means that either the email is going to the executive who really does own the account, or else that the attacker has already breached that executive's laptop to the point of having acquired his private key (and passphrase, if there was one), in which case phishing attempts to get a password would be utterly pointless (like trying to pick the lock of the front door when you're already inside the house).
So I email you asking for something. You say “send me your public key first”.
I generate a key pair and send the public key to you. You encrypt response giving me what I wanted.
How do you have any idea that I’m the person I said I am?
Well, I've been assuming that zikduruqe is competent and knows how to pick up a phone and call the person (looking up a phone number in the company database) to verify that the public key came from him via fingerprint-checking over the phone. Sometimes people leave steps out so as not to write essays in a comment box.
My confusion here is that if you're doing that, why bother with the cryptography? You can just look the person up in the company database, call them, and say "Hey! Did you just request a password reset?".
If one of your pre-requisites is "There is a trusted out-of-band way for me to validate comms with this person", the crypto is just extra bits.
The question makes no sense in this context. The identity verification problem is orthogonal to the encryption scheme.
This problem exists regardless of PGP. If someone's Slack is compromised:
With PGP: attacker gets credentials encrypted to their key
Without PGP: attacker gets plaintext credentials
But both fail at the same point: verifying who you're talking to. That's not a PGP problem, it's a "doing password resets over unauthenticated Slack" problem.
PGP does provide multiple identity verification mechanisms, e.g. web of trust, key signing, fingerprint verification, in-person key exchange, and Keybase-style social proofs linking keys to verified accounts.
The workflow described just doesn't use them. Identity verification is required for ANY secure credential exchange system; you either verify keys properly (signed by trusted parties, verified fingerprints, pre-enrolled, social proofs) or you have the same problem with passwords, TOFU SSH keys, or anything else.
Are you criticizing PGP for not solving a problem that the workflow simply didn't implement a solution for?
I’m saying asking somebody for a public key in the example scenario is pure security theater, no matter if it’s PGP or some other scheme.
That's only true if the key's authenticity isn't verified. If you just accept any key a person gives you, then yes, it's meaningless. But if you independently confirm the key's fingerprint through a trusted channel, it becomes a real security measure that prevents impersonation and ensures confidentiality.
The workflow as described (no verification step) is theater. But that's true for any credential exchange without identity verification, PGP or otherwise. The issue isn't PGP, it's skipping the verification step. PGP provides the tools (fingerprint verification, web of trust, key signing), but you have to actually use them.
I didn’t say the issue with this example scenario is PGP.
The scenario is theater (if you have an out of band lookup for verification, just use that. Don’t bother asking for pub keys).
Also in parallel PGP is trash.
The out-of-band verification is for initial key enrollment, not every credential exchange. You verify the fingerprint once through a trusted channel, then use that verified key indefinitely without needing the trusted channel again. That's the entire value proposition: establish trust once, communicate securely many times.
Without this, you'd need out-of-band verification for every single credential exchange, which doesn't scale.
As for "PGP is trash"... That's a different argument entirely, and you've provided zero technical justification for it. If you have specific criticisms of PGP's cryptographic primitives, key management model, or implementation security, make them.
No thanks, I think we’ve gotten all we’re going to get out of this thread.
I agree.
Neither Google nor Apple rely on PGP for vulnerability disclosure handling. Lots of organizations publish a PGP key, but in practice rarely use them.
Citation needed.
Both Apple and Google have updated these pages with security disclosure PGP keys in the last year.
https://support.apple.com/en-us/101985
https://about.google/company-info/appsecurity/
I design most corporate bug bounty programs the same way.
Sure, people rarely use PGP, but the ones that do are usually serious and high quality, and we let them skip the tier 1 queue. Script kiddies never know how to encrypt things.
It has not at all been my experience that PGP-encrypted bounty submissions are fast-tracked and most (almost all, in fact) good bounty submissions aren't encrypted. Google downplays PGP in the link you provided. Apple doesn't ask people to use theirs.
Are we looking at the same links?
It is provided as an option, the ONLY option, for those that feel encryption is merited for a sensitive report.
Google page: "If you feel the need, please use our PGP public key to encrypt your communications with us."
Apple page: "Apple security advisories are signed with the Apple Product Security PGP key. Sensitive security information may be encrypted to this key when communicating with Apple Product Security."
I think you missed some subtext that I thought was pretty obvious which is that most people don't encrypt bug bounty submissions in 2025.
> Neither Google nor Apple rely on PGP for vulnerability disclosure handling.
They support and rely on it exclusively for security disclosures sensitive enough to merit encryption.
"Sensitive enough" is smuggling in a presumption of yours that isn't supported by evidence. Whether or not submissions are PGP-encrypted (in my experience: they very rarely are) is uncorrelated with their severity.
In my experience building bug bounty programs for many high risk orgs, PGP reports are rare, as you indicate. Maybe a couple a year.
That does not make them any less critical or relied on. We always took them super seriously and read them offline because they were often highly sensitive real disclosures that merited being exposed only to a very small circle of people with security team decryption smartcards.
It is a safe assumption skiddies do not know how to use PGP so low skill reports with PGP almost never happened.
I would never run a bug bounty program without having an highly visible public key to encrypt highly sensitive reports to.
You haven't responded to my point. I would happily run a bounty program without a PGP key; in fact, I'd recommend not publishing a PGP key, and instead making arrangements to communicate a Signal identity.
Repeating a comment elsewhere on the thread so I'll keep this very brief, but it is in fact bad that PGP "does tons of other things that you will find are very useful".
age is so clean precisely because it does only one thing.
While GPG has other use cases; the intent is that those use cases are satisfied by different tools. Eg: signify for signing.
I’m also considering moving away from GPG, but the main limitation are signed git tags (for releases). For supports GPG or SSH keys. I’m not sure that I’m a fan of signing with SSH keys, I’d rather have first-class support for signify.
you can just have a dedicated ssh keypair for signing
> I'm now experimenting with `age`, which touts itself as "simple, modern, and secure encryption". If needed, I will use `minisign` for signatures.
I have also switched from GPG to age. When I wanted to start signing my open-source software releases because of recent supply-chain attacks, I first thought of Minisign, too. I tried it for binaries and even found a few third-party Git integrations (https://codeberg.org/SkyFox42/git-minisign, https://github.com/sug0/git-signify), then discovered that Git and GitHub supported signing with SSH keys (https://stackoverflow.com/questions/72844616). GitHub supports it in the sense that it will indicate a commit or tag is signed. I have adopted this approach: I sign tags with `git tag -s foo` and binaries with `ssh-keygen -Y sign`, and I have put the public key and usage instructions on my site (https://dbohdan.com/pubkeys).
gpg-agent was valuable to me because it let me use `pass` in scripts while maintaining encryption at rest. This prevented me from switching to `passage`. After surveying my options (https://github.com/dbohdan/pago/blob/6aa312e83113498a64abd9a...), I ended up forking pash (https://github.com/dylanaraps/pash) and developing the fork into an age-based password manager with its own agent. The developer of seniorpw has a nice feature comparison of `pass`-like password managers based on age (https://gitlab.com/retirement-home/seniorpw/-/blob/f1584cf42...).
I can say I am happy with the switch. If you use GPG for encrypting files, I can recommend it.
Is it post-quantum yet? I could not find indications of that.
No. age developer Filippo Valsorda has experimented with Kyber/ML-KEM and maintains a Go library for it, https://github.com/FiloSottile/mlkem768. The public key size is intimidating.
https://x.com/FiloSottile/status/1544803635237998592 (2022-07-06):
> A Kʏʙᴇʀ768+X25519 recipient would clock in at about 1660 characters.
> Classic X25519 age recipient for scale.
> https://paste.dbohdan.com/1mhc0nc-w7ks3/recipient.png [Alt text: A terminal window. The classic recipient on the first line takes about 2/3 of a line. The PQC one takes 16 lines.]
Oh, that's a shame.
I'd like to use something stable and supported for long term backups, so size doesn't matter. Pre-quantum is not something worth migrating to.
Is quantum computing a major issue for symmetric keys? I thought it was primarily an issue with public-keys?
The File Key is symmetric, but the header having recipient implies this is public key crypto.
So break the public key crypto (e.g. X25519), and you don't need to crack the symmetric key.
Also 128 bit? That's not quantum safe either, thanks to Grover's algorithm.
It uses key files that are 128 bits. With symmetric encryption, it’s equivalent to AES-128, so not really post quantum.
It has post quantum plugins, but those are third party plugins!
Yeah 128bit for symmetric is not enough, but it uses public key cryptography, right?
"RECIPIENT can be an age public key generated by age-keygen ("age1...") or an SSH public key ("ssh-ed25519 AAAA...", "ssh-rsa AAAA...")."
It has both public key and symmetric mode.
Even with public key, the file is encrypted in symmetric mode with a random key. The key is encrypted with pubkey.
The file format is built around asymmetric cryptography, so maybe going to 256 bits required some work that the authors does not want. Not sure.
Would have made sense to have standard ChaCha 20.
> The key is encrypted with pubkey.
Of course. That's how all public key crypto works. It's entirely infeasible to encrypt large payloads with a public keypair directly.
But this means that the symmetric key is entirely vulnerable to quantum computers. All you have to do is decrypt it.
> so maybe going to 256 bits
No, that's symmetric crypto key lengths, which are not the vulnerability when public keys involved are not PQ.
[dead]