Switching From Gpg to Age

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?

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.

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.

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

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.

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

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

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.

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