Hacker News Reader

Comment by lrvick | Hacker News Reader

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

View on HN

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.

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.

Perhaps you are not aware of PGP Web Key Discovery or Keyoxide.

I know of no solutions even close to this for Minisign or Age keys that does not rely on centralized corporations like Microsoft.

You're not responding to the main point. Here's tptacek's wording:

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

I love that age lets one reuse ssh identities and thus identity sharing systems. The single most useful thing I ever wrote was a tool to sync github identities with age. https://github.com/tarasglek/github-to-sops

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

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.

I think you're wildly over-indexing on a statistically insignificant number of users and their expectations

you're just affirming the consequent here, listing various properties of pgp as requirements

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

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.

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.

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.

I hit send too fast before I was actually done typing/thinking because I was going too fast, and you somehow got a response in seemingly instantly. My bad on this one.

> Did you not read the post I linked upthread?

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

That's your comeback? That PGP is too complex for me to use?

No? It is what the blog post you linked says, essentially. You linked it.

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.

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.

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

s/for an alternative/for an alternative or an explanation as to why OpenPGP is shit/

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.

This is absurd. You have not told me (or anyone else for that matter) what to switch to and why.

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.

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

Reply on news.ycombinator.com