As for the solution, it seems to explicitly not address recovery of lost keys/identities, which is however exactly the part that makes this hard for regular users.
That, and general name confusion attacks, I suppose: "I'm lxgr17@key, yeah, don't ask about the first 16. Oh also make sure 'key' is not the one with the Georgian lowercase e in the middle, that one's an impostor. Wait, actually, let me quickly spell it out in hexadecimal Unicode points..."
At least blockchain addresses have that going for them: They're way too long to even try and remember or spell out on the phone.
It's not "hard" for regular users; it's a complete non-starter for regular users. Every "non-custodial" or "self-sovereign" system of trusted identities founders on this issue: account recovery is the hardest problem in identity, and if you don't have a solution for it, your system is going to be a niche at best.
People have been coming up with these schemes for decades, and for that entire time, the near-universal de facto standard trusted identity system has been "Google accounts". People knew at the beginning that they were delegating trust to Google; they know it now as well; they are not going to adopt "names resolve to a key, the same key, in every application", no matter how many different names that scheme is given.
Yes, the UI/UX of decentralized systems is so difficult for users that it creates demand for centralized systems to manage it for them, Coinbase, Gmail, Github, Twitter, The Pirate Bay.
there's nothing wrong with a keychain or password manager holding your keys. passkeys already work exactly this way, completely transparent to the user. it's fine for most users.
Key loss is hard but not insurmountable. Social recovery / split-key custody seem like the right direction. Apple uses "recovery contacts" if you have advanced data protection enabled. A friend holds one share, Apple holds another but neither can recover alone. that's social recovery + split-key shipping to hundreds of millions of devices today
> That, and general name confusion attacks, I suppose: "I'm lxgr17@key...
pre-registering the obvious typo neighbors (lxrg, 1xgr ... etc) and it's cheap since handles batch-issue off-chain under a fixed 32-byte root, and strict ascii only charset ... etc could help mitigate some of this.
It's interesting to imagine how different the security landscape would be if human brains could easily transcribe a smallish quantity of high-value bits [0] and then compare two versions for exact equality.
I think the exact and trusted data-movement is the hard part. If we could instantly transcribe a 150 digit number (~512 bits) from eye to fingertips, then the actual memory/comparison could be done in any pocket-calculator, with X-Y==0.
A cryptographic identity is a public key as used in a public key signature scheme. So a particular person is represented by a ridiculously long number. That number can be shortened with some sort of hash to a shorter value to make a key fingerprint, which is a shorter ridiculously long number.
The scheme described in the system seems to use a blockchain to create a shared mapping between a name and a cryptographic identity. So a third party is still in control of that mapping, but there are a lot of third parties and most of them would have to conspire to forge a mapping. Then you could send a message to a name, rather than a number, with confidence that someone in the past picked that name and locked in the mapping between that name and the cryptographic identity.
The append-only, distributed nature of the traditional SKS PGP keyserver network seems to provide the same sort of thing. If you query several keyservers you can be reasonably sure that someone mapped a name (and email address) to a particular cryptographic identity sometime in the past. A single server operator can not forge a mapping without the possibility of that forgery being detected.
The thing is, people don't actually want a reliable name to cryptographic identity mapping service for end to end encrypted messaging. They instead want to be sure that they are securely exchanging messages with an particular flesh and blood person, and if you want to insure that you are back in the realm of ridiculously long numbers.
> The append-only, distributed nature of the traditional SKS PGP keyserver network seems to provide the same sort of thin
> most of them would have to conspire to forge a mapping.
The mapping is recorded in an immutable ledger (bitcoin) so forging is not feasible without breaking Bitcoin's proof of work. its a stronger guarantee than a key server.
> They instead want to be sure that they are securely exchanging messages with an particular flesh and blood person
comparing fingerprints doesn't verify a flesh-and-blood human either. "is this the specific person I mean" problem is still real and separate though.
`grace@key` binding gives you a stable, human-readable identifier you can hand out like an email address, build reputation on, and that anyone can use to verify posts made by you and message you without having to meet you in person. It solves the UX of using public keys as your identity. You can post online with a public key as your id (e.g. nostr) but its harder to build your online identity around it.
you can rotate the key underneath the name. with a bare key it becomes your identity, so rotating means becoming a new person and re-verifying with everyone.
> you are back in the realm of ridiculously long numbers.
not really. the long number is a disposable part, and there's a name above it. You can still exchange "grace@key" in person, and be sure you're talking to "grace@key"
> The same key, in every app, for every recipient. Not assignable to anyone else, not revocable, not subject to suspension. Yours forever.
This is impractical and the opposite of what we want. It's a required ID to use the internet, monitored by governments, tracked by corporations, and forever unchanging.
What we need is a system that allows people to easily create new IDs, that updates contacts that people choose. Think of a contact book that sends new keys to all contacts on every change. (Contacts would need to be always online.) It could update the key used on a website or not, depending on the users choice.
Breaking tracking and required IDs means flux and churn.
> It's a required ID to use the internet, monitored by governments, tracked by corporations, and forever unchanging.
There are clearly two opposing requirements.
One for anonymity, where people who need to be anonymous can create an identity that is verifiably the same person each time, but not a specific, identifiable, individual. The classic example is journalistic sources.
One for trust and verification, where the identity needs to be absolutely, permanently, associated with a specific individual. Online banking is the classic example here.
I don't think the same system can be used for both.
- If we can create multiple identities without verifying the human each time, as you say "flux and churn", then the second requirement is broken - there is no link between the identity and a verifiable person so the identity can't be trusted.
- If we can't create multiple identities without verifying the human each time, then the first requirement is broken - every identity can be associated with a specific human and there's no anonymity.
We could try some hybrid system where some identities are known people, and others are pseudonymns. But that feels like two systems wedged into the same box. The hard problems of absolutely correctly identifying a human so the second system works is still not solved, and irrelevant to the first system.
You are absolutely correct that the system that identifies individuals is incredibly attractive for states and large corporations, and so incredibly dangerous for actual humans. We need to be very, very, careful with this.
> What we need is a system that allows people to easily create new IDs, that updates contacts that people choose.
> Contacts would need to be always online.
That also sounds impractical.
> It's a required ID to use the internet
How does any of that follow? Having a reusable self-sovereign ID format for those scenarios where people want to share it is very different from having an authority-issued ID format that's mandatory for some interaction.
As a concrete example: I have an iMessage (CKV), Signal, WhatsApp, and GPG identity key, but I don't need to provide any of them when ordering pizza online. But what I can't do is choosing to use the same key for my same number on both e.g. Signal and iMessage to make it easier for people to switch between messengers without having to re-verify me.
A hypothetical shared key format would fix that, but would (hopefully!) still allow me to create multiple keys/identities for multiple contexts, and to not provide any persistent identity when it's not necessary.
If the ID is permanent then governments will require it, because they can. If it has attestations or endorsements, governments will require a government endorsement. Think about what China, Iran or Russia would do with a permanent ID being a standard. The US, England and the EU are not immune to the same impulses.
Always online is no different than an email account or website, and the rate of change would be, at least, minutes not seconds.
If governments want to do these things, they already can. Phone numbers are KYCed in many countries, for example, and many messengers mandatorily require them.
The lack of an interoperable key standard isn’t stopping them. (In fact, it’s even helping a bit by providing cover for MITM snooping)
look into "sealed sender" schemes, they allow the recipient to verify the sender identity without allowing anyone else to verify the sender identity. So making use of such a scheme allows you to prevent governments or corporations from intercepting even the metadata of communications (and of course E2EE prevents intercepting the contents).
I can foresee there will be valid use cases to re-assign a number (e.g. stolen, mistyped, wrongly assigned etc). One thing I learned about a real-world database for human information -- there will be a valid use case to do _anything_.
> Spaces takes this shape. (Disclosure: I work on it.) Issued names live in a binary Merkle trie. The root of that trie is committed to Bitcoin’s chain
Who can update and publish the merkle trie onto the blockchain? Is it only Spaces themselves who can? If so, this seems a little inferior to more direct blockchain solutions like the Ethereum Name Service which exists as a smart contract on a blockchain that anyone can use directly.
Operators are what assemble the bindings in the trie. Anyone can become an operator by bidding in an auction. You can read more about it at https://spacesprotocol.org
they don't have much power besides adding your name -> pubkey binding in the tree.
Not revocable doesn't seem ideal. Someone will have their identity stolen and they would have to give up their entire online identity and generate a new one.
> two parties have to be able to agree on which key grace@key is bound to without consulting anyone in particular. They need a shared, append-only record of which names exist and which keys they belong to. And that record can’t have a signing key to steal, an operator to coerce, or a committee to lobby
Having studied this problem space for some time, this is also my read of what the ultimate solution requires. That said, as the author also mentions, the biggest challenges in this paradigm are social, not necessarily technical. Therefore, I think the new solution requires a protocol approach rather than just a technical standard or implementation.
The KERI protocol (https://keri.one/) has been the best attempt I've seen at this. They focus on a similar concept, persistent long lasting identifiers built on top of cryptographic primitives, but they do so with a microledger approach than a monolithic blockchain as the root. The core primitive is what is known as a Key Event Log which tracks verified attestations of key transactions such as issuance, revocation, delegation, rotation, interaction, and so on. It is a very powerful concept that then facilitates stronger trust assumptions via end-to-end verification. And maybe most importantly, enables some very clean key management procedures that then can anchor the protocol behavior needed to optimize for those social challenges discussed earlier.
Regardless, adoption of KERI and other solutions like Spaces has not been very productive. I fear we've reached a tipping point where the external threats are too large now and top-down authoritarian-like solutions that address these issues head on will be the winners, leaving out dociety with very poor tradeoffs in such a critical area.
> Signal ships safety numbers because the platform might one day be compelled or compromised, and the architecture is meant to let you catch that. But almost nobody verifies
We have a solution to this! Wa and Signal both have key transparency. This uses cryptography to make it possible to verify that everyone is getting the same data[1]. Now your phone can check the keys listed under your username are all keys you made (and your contacts can check this too!)
Edit 2 (quick note): if you don't trust the app on your phone to verify your keys, then you also can't trust it to show you a valid security code, or do what the author proposed in their product spaces.
Edit:
It's also striking how similar (in essence) the current solution is to the solution the author is working on/proposing:
> Spaces takes this shape. (Disclosure: I work on it.) Issued names live in a binary Merkle trie. The root of that trie is committed to Bitcoin’s chain, used here as a widely-replicated, hard-to-rewrite timestamp service
Fundamentally the same: the name is your phone number (or alternatively in signal your username), key transparency also uses a merkle tree based structure. Instead of using the bitcoin chain as a consensus mechanism, key transparency implementations generally use trusted witnesses: simple servers that promise to only sign consistent versions of the merkle tree. This is better! Because essentially no clients (phones) have a local copy of the bitcoin chain, so you still have to trust a server to tell you what was posted in the bitcoin block.
For the rest current key transparency systems also have verifiers, which verify that the append only merkle tree is transformed into a dictionary legitimately (this is pretty compute intensive, and needs to be done by a trusted server too. WA currently contracts cloudflare as their only verifier). Spaces would also have to do this to be secure if they reach any scale, but this isn't mentioned in TFA.
Also a message for the author: Key transparency is cool tech, but you shouldn't reinvent the wheel! I hope you research current solutions more! You can ask questions in the transparency.dev slack (https://transparency.dev/slack/)
[1]: There are a bunch of details here. You need to check that everyone _is_ actually getting the same data. There are multiple ways to do this. The transparency ecosystem has generally stabilized on a system where you have trusted verifiers. But anyone (yes you!) can setup a server that can help monitor the chat app and trusted verifiers.
I have addressed key transparency in the post :) Key transparency does help with detection (still requires trusting third parties or having to check yourself) but the proposed protocol makes it not possible to forge the mapping to begin with.
> This is better! Because essentially no clients (phones) have a local copy of the bitcoin chain, so you still have to trust a server to tell you what was posted in the bitcoin block.
Not quite :) also addressed in the post. look at the end of "The CA of all CAs
" section.
I am co-founding a project that somewhat addresses some of this. The basis of it is a decentralized trust system built using human-readable names (think domain names), native mTLS, and post-quantum cryptography. This removes two barriers we've found: inability to easily confirm hashes (i.e. DIDs or fingerprints) and relying on a centralized trust giver (i.e. central certificate authorities).
Happy to share more if anyone is interested in this space: hn@sepositus.com. We're in shadow mode so not much public material at this point (although we do have a full PoC).
Everyone is trying so hard to re-invent PGP, while parroting that PGP is dead because some security influencers said so.
Well, there is a LOT of ongoing PGP modernization work on both specifications and implementations in recent years and my team and I at Distrust will be publishing a writeup on it any day now, as well as organizing yet another key generation and signing party in San Francisco next month.
PGP is not going away any time soon, and it is more relevant than ever.
No part of what's being proposed here has anything to do with PGP. They aren't proposing a "web of trust" with "key servers". They're proposing an immutable binding between names and key identities.
PGP's "self-sovereignty" comes from mutually agreeing with groups of people who already know each other to exchange files establishing identities. That is to trusted identity what the one time pad is to cryptography: a punt on the entire problem space.
> PGP's "self-sovereignty" comes from mutually agreeing with groups of people who already know each other to exchange files establishing identities.
Or between total strangers that met in person at a key signing party and agreed "you look like a human and not a bot to me".
We need human identity to be certified by humans using very long lived standard PKI primitives. Anything else, bots can easily monopolize to the point of being useless.
Rather than debate this here though yet again, I am working on a blog post which includes a lot of quotes, including one from you, to make a case for why PGP is still the best and most widely used and useful proof-of-human and self-sovereign PKI solution that exists, and why we should double down on it.
That's fine! It's perfectly reasonable to say "this isn't a problem worth solving". But you can't then say something else actually solves the problem by punting on it. Be clearer about what you're saying, instead of invoking the specter of "security influencers".
I am not saying it is not a problem worth solving. I am actually saying PGP actually solves the problem of which key actually belongs to which person.
There are dozens of keys claiming to be Torvalds that lack credible endorsements from high reputation identities, so those are easily ignored. The one that has been signing the Linux kernel for years and signed by many people putting their reputations on the line is the one we care about.
It is intuitive and does not need a math degree to understand.
It is unuseful to people with threat models that allow for entrusting their social graph to centralized identity systems managed by centrally controlled software supply chains that any compromised insider could manipulate.
For me and thousands of other Linux distro maintainers that maintain the core software supply chains and infrastructure that runs the internet, we cannot afford centralized trust graphs. Nothing else comes close to solving the problems PGP solves.
That is why it is an active IETF standard with modern cryptography and several actively maintained and widely used implementations.
Again, this works when your userbase is a small group of highly technical people who already have social connections to each other. But then again, so would just swapping Signal security numbers.
It completely and totally collapses in the face of non-technical users or broad adoption, which is one of multiple reasons that PGP remains a thing that a small set of people use.
Just to be pedantic about this: it does not in fact work; PGP has failed those kinds of user groups and platforms over and over again over the last 3 decades.
And yet many of the highest risk systems that exist, the whole foundation of the internet, several governments, major corporations, and thousands of high risk individuals rely on it because centralized options will never be agreed to by all parties, for good reason.
I have lost count of the orgs I have personally trained to use PGP properly in recent years.
In spite of your claims, PGP solves the problem it was designed to solve for the groups that need it most and the tooling is getting rapidly more accessible to a wider audience with more development energy today than it has ever had.
This is not 2016 PGP we are talking about anymore.
That's a weird thing to say. Yes, it is? What are you claiming is different about it? In fact, there are ways in which it has regressed from 2016's incarnation.
A renewed IETF working group that aggressively deprecated legacy ciphers and mandated modern ones with optional PQ crypto support (RFC 9580). Lots of actively developed rust implementations like rPGP, rsop, rpgpie, sequioa. Easy key provisioning and backup with smartcard support via keyfork. Smartcards with rust firmware by Nitrokey. Modern key distribution and trust bootstrapping via openpgp-ca, hagrid, keyoxide, etc.
GnuPG is admittedly garbage, but also that has not been a valid implementation of PGP specifications for a while and no one should use it anymore. PGP != GPG
I would strongly suggest taking a hard look at the last decade of thankless work going on to modernize the PGP ecosystem we all rely on directly or indirectly.
Currently writing up the above and a lot more in detail to refute years of outdated rhetoric on this topic so we can start having more useful conversations about it.
It's thankless because it's a bunch of folks at the county fair running around putting lipstick on all the pigs.
Having a bunch of implementations of an omnibus package that tries to be a crypto swiss army knife, written almost exclusively without the input of cryptographers, is actually not a desirable goal.
And none of the back seat drivers ever have alternatives to suggest that solve the same problems while having bothered to endure the IETF standardization process, and thus PGP will continue to be the trust foundation of the software supply chain of the internet for the forseeable future.
This fragile network we all use is made of a mountain of pigs that continually need their lipstick reapplied by people that do it for free or near free out of a desire to keep the whole thing running for everyone.
Said people even do it for the users that stay at safe distance pointlessly saying "We should go back in time and build it differently in unspecified ways!".
> Is your pitch that the people who call out problems with PGP don’t have suggested replacements for workflows?
Yep. I have read every single blog post I can find from critics. Most several times. As have most people that work on this stuff. Some were partly relevant when they were posted and even less relevant today. All of them completely missed the boat on the problems PGP solves that none of the alternative do, or have any serious suggestions for migration paths or standards changes.
I will be quoting most of those posts in a blog post in the next couple weeks on https://distrust.co.
Most of them have corporate alternatives to sell you which have no chance of adoption by standards bodies.
There's like, a whole section on https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th... that's specifically recommendations. The only ones that are "corporate" are chat (where PGP's UX and security model are absolutely horrendous in ways that both prevent mass adoption and make it comically easy to screw up, and where most of those problems are nearly impossible to resolve in a federated system) and I guess backups, if we consider Colin Percival to be "corporate" when he puts on his tarsnap hat.
Ah yes. That post. People send it to me all the time. It is my favorite.
It proposes that dissidents and security researchers from all countries from a wide range of backgrounds and beliefs on privacy, should all just accept the terms of service of their pick of two US based surveillance capitalism mega-corporations, trust they do not have any insiders or vulns, then reveal their identity to cell carriers in most countries, to get signal up and running, whose terms of service they must also accept, and then with the help of two corporations and their proprietary software supply chains, they can then submit an encrypted security vulnerability.
I legitimately laugh every time at the US corpo-brained takes in posts like these.
TL;DR: "Just let the US tech giants handle all identity and communication for the whole internet. What could go wrong? Super secure companies with great uptime like Microsoft GitHub can sign our commits for us and of course Google and Apple pinky swears to disobey executive orders to serve tampered updates of Signal to select devices. It will be fine."
The people that use their PGP keys to sign and securely distribute damn well near every binary that powers the internet are mostly in Europe, and not big fans of letting centralized and mostly proprietary US institutions control their online identity, let alone trusting them to not use a supply chain attack to read their private security correspondence. I for one have found a pile of serious vulns, including in GnuPG, and I do not have a Signal account and never will as I disagreed with the terms of service of Apple Google and Signal. Anyone that does not want plaintext disclosures would be wise to publish PGP keys for people like me. Thankfully most major tech firms still do, even if only to appease non US citizens and my fellow decorpoed americans.
Encrypted email is the only neutral decentralized and IETF standard comms tool we have. I say that as also a big fan of Matrix and would love to see it or something decentralized like it standardized but right now email is the standard so the snowdens and security researchers of the world should use PGP with modern ciphers and learn how to do it offline when doing high risk comms.
Even so, on the other side of this, having setup bug bounty programs for many orgs, the PGP encrypted/signed submissions from reputable folks were always the really spicy shit I would not want anywhere near a modern smartphone, and I would always decrypt them offline with a smartcard for good reason. I would not even consider being party to a bug bounty program that does not publish a PGP key to be maximally inclusive, even if they hate PGP.
Also re tarsnap. It does not even support smartcards, so just shove your private key for your entire filesystem in system memory, and back it up to a conventional password manager I guess? WTF.
Meanwhile with PGP you generate a key on a smartcard, you provide the public key to duplicity, and you can do backups without ever exposing your private key.
The alternatives suggested are strictly worse by any metric, and fail to understand the threat models of existing solutions.
GnuPG is not the final say for PGP any more than IE6 was the final say for the web. Migrating off IE6 took a while and so will migrating legacy systems off GnuPG. New users of PGP are thankfully mostly using new gen reasonably secure tools.
Just like IE6, GnuPG abandoned the global standardization processes and in doing so forced an expensive migration to successors.
Global changes on the internet take decades in part because of all the people far removed from the process spreading outdated information and demanding we give up on standards and move the whole world to centralized solutions that do not even solve the same problems, like Java Applets, Adobe Flash, or Signal.
Meanwhile those standardizing and rolling out longer term solutions roll their eyes and keep doing the work.
If everyone is moving to new software, in a migration that is barely 5% underway, why would you migrate to PGP of all possible cryptosystems? It's 2026.
I'd pose this challenge to you: find the most reputable cryptography engineer or academic cryptographer you can find that believes this is a good idea. I'd be interested if you could find even one. Fair warning: some of my confidence talking down PGP comes from knowing what the conventional wisdom among cryptographers is about the PGP cryptosystem.
New software that is compatible with any keys generated with good-enough ciphers from the last decade. Compatibility wins.
If we are going to play the appeal to authority game, I could just as easily challenge you to find any willing to publicly point out any serious issues with the current PQ focused OpenPGP standards with implementations using libraries by accomplished cryptographers. I am sure they would appreciate constructive feedback. Encourage them to join the specification process and recommend specific alternatives and migration paths.
I also wonder if we could find any that would not scrap TLS DNS and a lot of IETF protocols that run the internet today if they could. Decentralized protocols are messy but anything that tries to replace them without first taking the time to understand the current uses and migration path has no hope of success, and that is brutally difficult political work full of careful compromises.
Famous cryptographers have long advocated for things like tcpcrypt, and I even agree with them, but it will probably never happen. Too disruptive. We are still rolling out IPv6 FFS. When faced with an established global internet, compatible lower disruption migration steps are the only way forward as most experienced security engineers would begrudgingly agree.
Cryptographers should absolutely focus on the security of the ciphers, but when it comes to applications, and human privacy and security goals, and human to human trust bootstrapping protocols, the conversation has to get a lot wider. It is normally dominated by security engineers like us close to the hands on use cases, and the people doing the hard work in the working groups and tool development circles that understandably wish to quietly read different takes from a safe distance.
Cryptography basically always explodes at the joinery. One of the guiding principles of modern cryptographic tools is designing implementations that do not have footguns, where the default behavior solves the default threat model and dangerous things are outright impossible. This has been apparent in the string of GPG security failures over the past several years. It's not that somebody breaks RSA or AES. It's that the tools willingly emit bad data because of bad error handling, and then users are told they were holding it wrong and it's their fault for choosing a bad implementation.
Maybe it's worth asking if the reason cryptographers aren't engaging with the work to "modernize" PGP, and that instead we're seeing them building and shipping individual focused solutions to specific workflows, is perhaps because their constructive feedback is akin to ~"you are fundamentally trying to prop up a house of cards that should not exist"
So you are saying that the solution is that we go to the majority of active and reputable PGP keyholders, Linux maintainers, and tell them to stop signing the binaries that run the internet, and just yolo, because that worked so well for NPM?
I’m saying several things, but since you’re really focused on Linux package signing, I’m saying about that: PGP is a bunch of theatre there and distros should use minisign instead.
Linux package signing is a great example of where PGP is goofy. Users of Linux distros get their root of trust by downloading a keyring from the exact same place they download the distro ISO. To a rounding error, no users are checking a trust path from them to a distro maintainer, nor does the trust path between one maintainer and another matter.
Distros are themselves centralized entities. They already run bug trackers and forums and centralized package repos that necessitate an authentication system.
So PGP effectively becomes a clunky behemoth whose output is just “every package has a signature that is checked against a centrally curated set of keys that get shipped around to users”.
> PGP is a bunch of theatre there and distros should use minisign instead.
Okay so drop the IETF standard, web of trust, smartcard support, and external key discovery mechanisms to prove the whole keychain was not swapped out with a fake one, and just have everyone generate minisign keys exposed to system memory with no trust link backwards, and then sign things with probably the same algorithms. But then we cannot sign commits or code reviews with minisign because non standard, so i guess use ssh keys for those, and then maintain multiple keychains for each person.
Minisign is strictly worse in every way. Your camp will never convince Linux maintainers to switch with this pitch.
Many of us actually do verify the web of trust, extensively. I have many Linux maintainers in my own keychain independent from their usage in linux distros. Minisign has no such key distribution and accountability system.
> Okay so drop the IETF standard, web of trust, smartcard support, and external key discovery mechanisms to prove the whole keychain was not swapped out with a fake one, and just have everyone generate minisign keys exposed to system memory with no trust link backwards, and then sign things with probably the same algorithms. But then we cannot sign commits or code reviews with minisign because non standard, so i guess use ssh keys for those, and then maintain multiple keychains for each person.
I'm going to take "the appeal to authority game" as an agreement that you think it's unlikely you'd find such a person to vouch for a modernized rebirth of PGP, or really any continued use of PGP.
I could name a few off the top of my head, some of which have audited my teams work, but I do not want to put specific people on blast. Most cryptographers I know tend to prefer math to internet controversy and I do not blame them.
I have dozens of more examples of high risk orgs with cryptography teams relying on PGP I am compiling for my post right now. Added a bunch of extra ones just for you.
Honestly from my side of the table, it is the anti-pgp camp that appears to be the loud minority. The world quietly runs on "dead" PGP technology so deeply that any calls for a complete replacement without any compatibility or trust transition path are clearly under-researched and should not be taken seriously.
I have a hard time imagining many cryptographers deeply aware of the impossibility of any rapid transition away from PGP would suggest we abandon the migration to secure modern ciphers now.
A lot of people would like to -eventually- move away from openssl too, myself among them, but not updating to openssl 4 and beyond in the short term would be a world burn kind of move.
If the measure here is "I met this person at an event and they were a human", and the protocol becomes actually important for proving personhood, what is the measure that stops somebody from turning up to a bunch of events and getting "human" keys signed to then repurpose for bots?
Because this is too expensive to scale, and people talk in small circles about who has signed who. Good luck inventing thousands of fake identities with a long trust history and reputation with this approach.
Botmasters like situations where they can hide offline and buy bots blue checkmarks with stolen credit cards.
This is a fun kind of paradox. Right now it wouldn't scale well because signing parties are a niche nerd activity and having your identities signed by other GPG users doesn't really help with anything you'd want to do with a bot.
But if you were to actually succeed in making key signing parties a more common thing that people used to test for human-ness, and that test was tied to meaningful things online, it would both become easier to fake and more valuable to fake.
When you sign a key you pick a trust level. If no one reputable has ever trusted a persons key with a higher level than "human", then that key should be subject to significantly higher scrutiny.
If you look at my key, you will find it is heavily connected to the keys that sign most linux distributions, bitcoin, and commits to the Linux kernel today.
If those 5444 linked identities that long pre-date AI are colluded to create a fake me and fake people that signed people who signed me over the last 25 years, and got those fake fingerprints in the keychains of every distro and got matching fingerprints on thousands of privately owned sites, we indeed have serious problems.
Yes, that would be the conundrum I was describing. If your plan were to work, the idea of a signer being "reputable" would be watered down into nothing.
Well, it is working as intended, right now, and the binaries running on the servers we are communicating with right now were likely signed and validated with Linux maintainer PGP keys because it is the only standard and decentralized option.
PGP does not need mass adoption to function, but with solutions like keyoxide offering a more accessible trust onramp, it is there for anyone that wants to self certify and take control of their own identity today, and get signed by trusted community members tomorrow at a conference.
It is hard enough for people to keep up with one keychain, let alone a dozen of them for every use case in their lives.
PGP keychains allow you to have a single 24 word mnemonic seed to recover your entire digital identity, data access, etc. The UX is strictly better than the commonly suggested hodge podge of flavor of the week alternatives.
I've struggled with PGP with the idea that I can't quite express "I'm signing as this specific User ID by using this specific signing subkey"... The only way I've found to reliably express that is to maintain completely separate keys. Is there anything in the works to give ergonomics around this?
You should only be signing other peoples keys with your master key which should never touch an internet connected operating system. Subkeys should have limited privileges and be easy to lose or rotate as needed, but can all live under the same master offline identity key, which acts like a personal CA.
The first bit seems possibly solvable with private set intersection. You can publish a salted hash of everybody you trust, and I can compute hashes of everyone I trust with your salt to see if we have anyone in common. Then I check the signature corresponding to the salted hash I like, and hopefully it doesn't reveal anything you don't want to reveal.
I don't know if anyone has actually done this in practice. Does it work?
Having a public graph is critical for trust in Linux distributions. All it means is a human met you and agreed you are human and signed your key. It does not imply you are friends.
It is pretty useful for someone totally outside the trust graph to be able to prove the key that just signed the latest release of stagex is only a couple steps away from the keys that sign debian and the Linux kernel. Keys that long predate AI.
Public trust accountability is exactly what we want from people responsible for the legos that make up the internet.
You can of course have private signature packets revealed as needed though.
As for the solution, it seems to explicitly not address recovery of lost keys/identities, which is however exactly the part that makes this hard for regular users.
That, and general name confusion attacks, I suppose: "I'm lxgr17@key, yeah, don't ask about the first 16. Oh also make sure 'key' is not the one with the Georgian lowercase e in the middle, that one's an impostor. Wait, actually, let me quickly spell it out in hexadecimal Unicode points..."
At least blockchain addresses have that going for them: They're way too long to even try and remember or spell out on the phone.
reply