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.
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.
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.
You want to be sure it's a particular person the you need to establish in-person trust.
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.
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.
> 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.
Always online is no different than an email account or website, and the rate of change would be, at least, minutes not seconds.
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)
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.
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.
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).
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.
For now check out this post about how we use it to build trust in the Linux ecosystem today: https://kron.fi/en/posts/stagex-web-of-trust/
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.
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 comment thread is sure to be interesting.
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.
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.
Decentralized human trust, or centralized corporate trust. Pick one.
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.
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.
Botmasters like situations where they can hide offline and buy bots blue checkmarks with stolen credit cards.
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.
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.
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.
Which bit of PGP?
Which is the thing, we do need a single key that can be used for all those things. So we get PGP.
I thought everyone was "trying so hard to re-invent PGP".
> we do need a single key that can be used for all those things
We do? This is not obvious. Why does my disk encryption key need to be the same that I use to sign binaries that I release?
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.
Standards make interoperability a lot easier.
1. You reveal your social graph
2. Different instances of the key can be differently signed
For someone to sign your key that information has to be stored on your key or in a central location.
I don't know if anyone has actually done this in practice. Does it work?
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.
> "Supply is capped at about ten per day. Individual squatting (buy at auction, hold, resell) is possible. "
Won't this mean that squatters will keep buying the top-alexa domains for the first few years?
I'd have liked to see a comparision with other "crypto"-led infra in this space. .eth/ENS, namecoin, .box, .bit for eg.
Why write in such a silly way? Do you mean "Spaces does this"?
We do, you just don't know about:)
SDK: https://github.com/CipherTrustee/certisfy-js
Web trust use: https://bsky.app/profile/bitlooter.bsky.social
Some examples of how you could leverage it: https://blog.certisfy.com/
Happy to answer questions.
this article shows "alice@key" which looks very sensible.
then one click away, joining spaces, you can only get "horse-battery-staple@key AGE age1hsuwgduwhdiehhduwhdiheudhwi..."
and one cannot even pick the first part! pure insanity!
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.