Switching from GPG to age

Some notes about my switch from using GPG for encryption to using age, and how it has changed my workflows.

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

keyfork

An opinionated and modular toolchain for generating and managing a wide range of cryptographic keys offline and on smartcards from a shared bip39 mnemonic phrase.

Forgejo: Beyond coding. We Forge.
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.

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

Lance R. Vick - Keyoxide

Modern and secure platform to manage a decentralized identity based on cryptographic keys

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

I do indeed strongly believe decentralized identity is critical to free internet. I cannot imagine any good outcomes from trusting a small handful of corporations that answer to a small handful of governments to decide what identity and access mean online.

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.

This is what I mean when I suggest people who use PGP are LARPing. It's perfectly reasonable to prefer decentralized systems to centralized ones or to think that it's critically important to the future of the Internet that we pursue decentralization. But cryptosystems need to function when lives are on the line; the preference of an system with inferior, flawed cryptography, in pursuit of a philosophical goal about Internet governance, betrays the fact that the security you're after is only a secondary goal.

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.