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.

No, PGP is also a shit show stuck in the 1990s.

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/

The PGP problem

The PGP problem

Latacora

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

pkcs11-openpgp-notes

OpenPGP use of PKCS #​11 and PIV devices. Also see https://codeberg.org/heiko/openpgp-pkcs11 and https://codeberg.org/heiko/openpgp-piv

Codeberg.org

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.

The OpenPGP Modification Detection Code is Actually Good [The Call of the Open Sidewalk]

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.

PGP FAN [The Call of the Open Sidewalk]

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.

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

Cool, so we got two people here who kept saying "PGP is shit", but when asked for an alternative, they weasel out with "no thanks", or "I will not [say]"? Yeah, okay. Got it. I hope you realize it weakens everything you have said. Hell, there is nothing to weaken to begin with!

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

While obviously I can present alternatives to OpenPGP and have done so, including on this thread, it's important that you understand that this isn't how engineering works. If something is observed to be flawed, it's flawed. Whether or not alternatives are presented with the observation doesn't change its validity.
I understand what you are saying. Can you tell me in what ways OpenPGP is flawed and what the alternative is to achieve everything GPG supports? Legit question. If it does everything GPG does, but does it better, then people (including me) may switch.
I'm really not interested in whether you switch. To me, for the problem domains we're really talking about, this is like talking someone out of wearing a Kangol hat. You do you.