Great concise description of the problem.<p>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.<p>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..."<p>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.
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.<p>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.<p>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.<p>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 same key, in every app, for every recipient. Not assignable to anyone else, not revocable, not subject to suspension. Yours forever.<p>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.<p>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.<p>Breaking tracking and required IDs means flux and churn.
I tried to follow the links, but could not discover the expected cost of a record creation.<p>> "Supply is capped at about ten per day. Individual squatting (buy at auction, hold, resell) is possible. "<p>Won't this mean that squatters will keep buying the top-alexa domains for the first few years?<p>I'd have liked to see a comparision with other "crypto"-led infra in this space. .eth/ENS, namecoin, .box, .bit for eg.
The entire premise of this article is wrong!<p>> 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<p>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!)<p>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.<p>Edit:<p>It's also striking how similar (in essence) the current solution is to the solution the author is working on/proposing:<p>> 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<p>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.<p>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.<p>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 (<a href="https://transparency.dev/slack/" rel="nofollow">https://transparency.dev/slack/</a>)<p>[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.
>We have public-key infrastructure for machines. We don’t have it for people.<p>We do, you just don't know about:)<p>SDK:
<a href="https://github.com/CipherTrustee/certisfy-js" rel="nofollow">https://github.com/CipherTrustee/certisfy-js</a><p>Web trust use:
<a href="https://bsky.app/profile/bitlooter.bsky.social" rel="nofollow">https://bsky.app/profile/bitlooter.bsky.social</a><p>Some examples of how you could leverage it:
<a href="https://blog.certisfy.com/" rel="nofollow">https://blog.certisfy.com/</a><p>Happy to answer questions.
[flagged]