Switching from GPG to Age
luke.hsiao.dev
luke.hsiao.dev
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.
Also, again, use keyoxide which is a modern decentralized alternative to keybase. You can vouch for yourself to bootstrap trust.
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.
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.
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:
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...
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.
But to your point, not nearly enough people have a concept of a desire to want digital sovereignty. Ownership of their own identity in a way a company has no control of.
And the ones curious about this concept, find the barrier to explore it impossibly high. That is why I have been so convinced in recent years that UX and social dynamics matter in cryptography as much as the math behind it.
That is why we put so much thought into keyfork. We realized it has to be one or two commands tops to be up and running with a new keychain or no one is going to do it.
You see all sorts of different variants of this argument. People cling to PGP because they believe SMTP email needs a future. What does that have to do with protecting the life of a user? Nothing. People cling to PGP because of concerns about open source. Same issue. Not wanting to run things on their phone. Same issue.
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://www.nitrokey.com/news/2021/new-nitrokey-3-nfc-usb-c-...
https://doc.qubes-os.org/en/latest/user/security-in-qubes/sp...
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
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.
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.
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.
Oh THAT is why you are steering people away from OpenPGP, gotchu. I have read it a long time ago. I remain to be convinced. The blog post just reeks of "I can't use it, too complex for me therefore it sucks". Yeah, it can be misused, I do not deny that.
(BTW I could not care less about e-mail.)
In fact, I said "The blog post just reeks of "I can't use it, too complex for me therefore it sucks"".
I do not know if you have written it or not, if you were the one, then yeah.
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.
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.
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.
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.
Thankully, because of standards, we can switch to a leaner library set without breaking compatibility.
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.
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.
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?
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.
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.
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.
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 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.
> (that the other commenter was simply wrong that the archaisms in PGP/OpenPGP are a mere consequence of GnuPG and avoidable by avoiding GnuPG)
Didn't read it like that though, it read like "OpenPGP is shit", and I could quote you where you are claiming exactly that:
> outmoded fundamentally, not just by one implementation
You said this, about OpenPGP.
Welp.
You cannot be taken seriously. At this point I think you are full of shit.
If you care about security, you should care about people switching, but you do you. Keep it to yourself, keep it a secret, and keep bitching about OpenPGP, I suppose.
Would you rather recommend Sequoia-PGP or what?
If that is the case, you probably want:
1. a long lived keychain
2. a way to securely load private keys into smartcards such that they cannot be stolen by malware
3. a strategy to recover lost keys
4. a strategy to migrate from one keychain to another one
5. a way to notify people/software to stop encrypting data to your old key
6. a way to switch between multiple competing software implementations with a long established spec
The PGP ecosystem has you covered on all points. Age does few of these, and none of them well.
Doing things the right way takes a bit more up front thought and time, and you will thank yourself later.
That said, for the sake of compatibility, keyfork keys can be used with any pgp toolchain, as well as with signify, age, or whatever.
What’s more, it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer. All that is needed for that higher layer to “compile down to” or emit some kind of key allowlist or denylist that can be consumed by the cryptosystem layer beneath it. The work-in-progress VOA[0] spec is an example of such an upper layer.
[0] https://uapi-group.org/specifications/specs/file_hierarchy_f...
Encrypted files are encrypted to a key. It could be a one time use key encrypted to another key as PGP and Age both do, but still there is a long lived secret a user must maintain somewhere, somehow, and have a strategy for backup, rotation, discovery, validation, etc etc.
> it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer.
There are a ton of other ways these problems could be solved. If we had a time machine we would go back and design way different tools and specs to address the problems PGP solves. We would redesign the internet too.
What I take issue with is people recommending age or minisign or signing with ssh keys when all of these just pretend the problems PGP solves do not exist, and thus set people up to fail.
Of course. I'm not suggesting that there's no need to have long-lived private key material. But that does not require some thick GPG-keyring-style concept (especially one that includes both public and private key material). Something like a directory of private keys (like with SSH) fits the bill here and yet bears precious little resemblance to GPG's system.
> have a strategy for backup, rotation, discovery, validation, etc etc
Again, I see no reason to bake this stuff (I'll call it "identity management") deeply into the cryptosystem itself. Especially because different encryption use-cases have vastly different needs. The identity management needed for a one-time message exchange between humans shares little structural similarity to that needed for authenticating OS packages from multiple parties. These two use cases are almost entirely disjoint, I daresay. To the point that any effort to devise a shared abstraction will only muddy the waters since there is so little intrinsic similarity.
> What I take issue with is people recommending age or minisign or signing with ssh keys when all of these just pretend the problems PGP solves do not exist, and thus set people up to fail.
I can agree with this for sure. If you need these various features, then age et al. do not fit the bill.
On the other hand, in cases where these systems have adequate functionality or can be shimmed up by other systems, they're lightweight and easy for users to comprehend.
Take commit-signing with SSH keys to provide verification mediated by GitHub. Everyone (lol) knows how to generate and manage an SSH key. Easy enough to set up git for signing with that key. Then GitHub uses its own identity layer to show users what commits are verified and which aren't. From the user's perspective, it's super lightweight, easy. When it comes to cryptographic signatures with long-lived identities, it basically doesn't get easier than this.
Of course, that GitHub example misses some features, and isn't perfect. But it captures a lot of the value of signing with a bare minimum of error-prone work for the user.
Your argument doesn't cohere.
I feel like the rhetorical sleight of hand PGP advocates too often fall back on is the idea that while there may be tools that do some of what PGP does, and those tools put together may comprise a superset of PGP's functionality, there is no one tool that does everything PGP does by itself. But that's the whole point. Part of what makes PGP so bad is that it's a Swiss Army Knife.
If a human focused cryptography tool gives a user no way to know if they are encrypting to the correct public key of someone else, or no way to distinguish a real signature from one of an impersonator, then the tools failed to do their job.
Age is maybe useful for personal encryption use cases, but it is no way a replacement for all encryption use cases of PGP, especially between humans. Let alone signing and authentication which would be a prerequisite to do this safely.
My guess is that at this point more professional environments (think on the level of "companies and projects") have integrated age and minisign than have integrated PGP, which is striking given how long PGP has had to demonstrate success. In 2025, if you built a new identity system for, say, code, virtual machine or container provenance, or secure messaging, your competent security team would very likely shoot you down.
This is just another instance of the same sleight of hand I identified upthread. It's actually bad that PGP does all this stuff, for the simple reason that different real-world problems have different cryptography requirements. For that reason, competently built systems don't do what the PGP ecosystem does, of fielding a Swiss Army Knife instead of a chef's knife or a table saw. Then the PGP ecosystem tries to ding those tools for not repeating PGP's mistake.
I know of no solutions even close to this for Minisign or Age keys that does not rely on centralized corporations like Microsoft.
> PGP does an absolutely dreadful job of key discovery, and further, there is no reason to couple one mode of "key discovery" to a signing tool. Different business domains will have different optimal key discovery architectures.
Here's how I expressed it to you:
> Again, I see no reason to bake this stuff (I'll call it "identity management") deeply into the cryptosystem itself. Especially because different encryption use-cases have vastly different needs. The identity management needed for a one-time message exchange between humans shares little structural similarity to that needed for authenticating OS packages from multiple parties. These two use cases are almost entirely disjoint, I daresay. To the point that any effort to devise a shared abstraction will only muddy the waters since there is so little intrinsic similarity.
This way you get git for change tracking on your secrets and who-has-access-to-secrets and key rotation and this can be trivially expanded to other forges.
Its easy to introduce age this way into any modern project whereas gpg would-ve been a non started on most teams I worked on.
disclaimer: this was mostly vibe-coded because I really did not want to work on this and wasnt sure if teammates would adopt it. Then it just worked, so stayed ugly inside
But this is what happens when people try to re-invent the wheel without thinking through all the problems the original solution solved.
Also I do put these systems to the test, regularly, and rest billions of dollars of infrastructure on them.
Anyone is free to hit up my team in our public channels with any PGP gotchas. Happy to help.
It is easy to point at past black eyes of any technology, but I stand by PGP for the use cases we recommend it for today as the least bad option for those use cases.
Also, Hagrid keyservers (openpgp.org) do email verification now and are a new generation of keysever built from scratch. The legacy ones are a mess and can be ignored.
Today though, Web Key Discovery, PGP DNS records,and Keyoxide are much better ways to discover and distribute keys and signatures now.
An engineer coming from a corporate world where everyone is comfortable with a model of centralized backups, centralized identity, and centralized trust is going to have a very different perspective than say, a Linux distribution maintainer, or those maintaining they core backbone of the internet.
I am closer to the latter camp, and obviously have my own biases here, but in spite of them I package Age in stagex, and we support it in keyfork, just so people have choices. Choices are always a good thing.
That said, it is my opinion that age does not even begin to approach the threat model or use cases PGP solves for. It does one thing, and it does not even do that thing as well as PGP does in most situations I can think of.
Just because someone is experienced in cryptography does not mean they have had significant exposure to environments where decentralized identity and trust are a hard requirement and where no alternatives to PGP exist, and where there is no customer service or IT team to bail you out, which really changes how we tend to think about these problems.
In my experience cryptography engineers that work on decentralized open source systems like Tor, blockchains, Linux distributions, etc, tend to strongly favor solutions like PGP as not "good" but the "least bad" option to avoid any single point of trust or failure.
Those that have spent their careers in the proprietary FAANG world tend to support using solutions like Fulcio or sigstore and using OIDC to let a central party sign for you with "keyless signing", which to me, is total nonsense. I assume anything that I cannot verify the integrity of for myself to be compromised.
Also a solution that significantly reduces attack surface enough to motivate a migration from PGP in all the areas it is used, and a specific strategy to migrate everything to it.
Also form a standards team to maintain the spec to keep all implementations compatible so this work is useful long term.
If all of that happened I would seriously evaluate it and likely even help promote it. Few understand the shortcomings of PGP better than those of us that heavily rely on it!
Until then I suggest improving upon what already exists, or at the very least stop steering people away from the best effort solutions we have today and all the hard work from hundreds of people that go into maintaining them for free.
in practice, few, if any, of your enumerated "wants" are valuable enough to outweigh their costs to complexity
this should be pretty clear from the fact that statistically nobody uses pgp
[1]: https://manpages.debian.org/trixie/gpgme-json/gpgme-json.1.e...
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.
Can you do this with Age? If not, then I am going to stick to GPG.
Can Age interfere with all SmartCard usage? No clue.
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.
Can you use GPG-agent for non-resident passkey challenges?
I also have Yubikey setup, but haven't thought of this.
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).
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.
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.
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.
They do not get their credentials until they do so. And once they do, our security posture gets better and better.
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?
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?
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 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.
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.
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.
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.
> 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 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.
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 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."
They support and rely on it exclusively for security disclosures sensitive enough to merit encryption.
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.
I also may want to do this anonymously.
Signal is the wrong tool on both counts. Fine to have as an option but I would never have that as the only option.
More of them required password-protected ZIPs than PGP, so much so that we had a whole complicated document to ensure we were using the versions of ZIP file programs that used AES and not Bass-o-matic.
Apple and Google routinely get findings worth 6-7 figures that aren't PGP encrypted.
PGP-encrypting bug bounty submitters are mostly LARPing.
I will take the Pepsi Challenge with you on experience with bounty programs if you'd like. But here's another question: have you ever been on a major-vendor embargo list before? Was it your experience that those embargo lists were uniformly PGP-encrypted? (I can spoil this one for you if you like).
Tell me more about how major vulnerability disclosures depend on PGP, please.
This just seems to be an appeal to authority. I will just say your credentials do not impress me.
Lets just stick to two security engineers on different sides of the same industry having a technical merits discussion.
In any event I did not once claim PGP encrypted reports are common, but I can say of the dozens I have received, most were very high quality from actual security researchers, and some have made me very happy I insisted such reports be decrypted offline on a machine I absolutely trust.
It is good to give people options, and especially at least one that can be used anonymously with a fully open source operating system using a decentralized very widely used and established standard.
I for one have made more than a few very sensitive security reports and do not own a Google or Apple controlled device or a Signal account.
My point still stands.
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.
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 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.
It has post quantum plugins, but those are third party plugins!
"RECIPIENT can be an age public key generated by age-keygen ("age1...") or an SSH public key ("ssh-ed25519 AAAA...", "ssh-rsa AAAA...")."
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.
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.
But whatever. Now I know. Both the choice of symmetric key length AND the choice of public key algorithms independent of each other make this format not PQ.
Why anyone in their right mind would migrate to such algorithms in 2025 I have no idea, and especially coming from someone like Filippo it's baffling.
Those already on PQ are better off staying. Those who are not should move to a PQ, not this.
The public key algorithm has been frustratingly blocked on the IETF and CFRG, which are taking more than 15 months since FIPS 203 to stabilize a simple hash-based hybrid combiner.
I still stand by that one should not migrate to vanilla `age` until the public key part is PQ, or one will need to do two migrations. The incremental improvement from going GPG to age seems pointless given the timelines.
If PQ compliance is urgent, then sure, migrate to age+PQ plugins. Yes I share the frustration about how long it's taking, so in the mean time for PQ requirements I can't get into, I did for some installations need to migrate to a temporary pre-standard (but still holding up) PQ layer.
And I'm itching to migrate to something standard (or at least de facto standard) when it comes.
Frustrating, but understandable, that many people are making excuses that they are focusing on key exchange, not communication over time.
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.
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.]
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.