> That is very silly. I founded and ran what was at the time...

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.

If I as a security researcher want to send a super sensitive disclosure to an organization like "I have reason to believe your devices are compromised", I want to be damn sure it goes to a PGP key held on smartcards that decrypt reports on airgapped operating systems.

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.

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.

In my experience building bug bounty programs for many high risk orgs, PGP reports are rare, as you indicate. Maybe a couple a year.

That does not make them any less critical or relied on. We always took them super seriously and read them offline because they were often highly sensitive real disclosures that merited being exposed only to a very small circle of people with security team decryption smartcards.

It is a safe assumption skiddies do not know how to use PGP so low skill reports with PGP almost never happened.

I would never run a bug bounty program without having an highly visible public key to encrypt highly sensitive reports to.

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

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.

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.

> Neither Google nor Apple rely on PGP for vulnerability disclosure handling.

They support and rely on it exclusively for security disclosures sensitive enough to merit encryption.

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