I've been working on a project for the last six months that brings mTLS to the masses. Meaning, post-quantum end-to-end encryption with human readable identities. It uses a decentralized root of trust for, basically, a lot of the history this article covers.
Human readable identities are the hardest part (unless you just mean BIP-style word chains). What’s your approach look like? How do you prevent collisions?
You register a DNS-style name. Registrations lasts a year with a 3 month post-expiration window to reregister, otherwise it gets released back. The system goes out of its way to make name trading uneconomical - specifically to work against speculators and name-sitters from coming in and ruining things.
Ah, ok. Is there a fallback for using bare keys instead of human readable names? If not, you have just recreated a central gatekeeper problem; you could be ordered to terminate name service for someone. Unless it’s using some decentralized crypto system like eth.
Optional human readable names could be a good system combining convenience with resilience.
It's using a decentralized backend. No, it's not using any existing blockchain, nor does it have any tradable token. It does have some blockchain properties, but the main layer is built on top of libp2p.
Agreed it's a very hard problem. We're in the process of forming a syndicate of like-minded parties who are interested in seeing this come to life because the model itself has no exit plan and is basically anathema to traditional capital funding.
Also, to be clear, names are hashed/salted in the backend with Argon2ID and a rotating salt. So the name index itself isn't enumerable, but it doesn't necessarily guarantee names are private once they are shared publicly. Theoretically you could lookup someone based on their public key without knowing their name - so in that sense it's somewhat close to what you're describing.
Interesting. Yes, the possibility of direct key lookup would solve the problem, especially if existing contacts remain connected even after name expiration/revocation.
Perhaps you could do a name presale, although I’m not sure that would be enough funding. I look forward to hearing more about it.
We'll probably do a name presale, but this is deep tech/big infra we're setting up, so it wouldn't be enough. That's why we're busy partnering with like-minded individuals to do a non-traditional raise. We did start with the more traditional route, but all of them (including a16z) were baffled by our choice to not resort to degenerate behavior (i.e. a16z in particular refused to play game without making a token and listing it on a DEX).
Anyone interested can reach me directly at hn@sepositus.com (this is a SimpleLogin alias to protect my email from spam).
A few things, Zookos conjecture dates to 2001. It was an observation, not a formal proof of anything, nor a physical limit, as he said in the paper: "I didn't prove that it is impossible to have all three features"
So without conflating Zooko with all the commentators who followed saying, "but Secure meant ...", lets look at the real definition from Zooko:
1. distributed (in the sense that there is no central authority which
can control the namespace, which is the same as saying that the namespace spans trust boundaries),
2. secure (in the sense that name lookups cannot be forced to return incorrect values by an attacker, where the definition of "incorrect" is determined by some
universal policy of name ownership),
3. and having human-usable keys.
So the system we are building (I am the architect) Satisfies all 3. I went and added a fourth, which is privacy. I say:
4. Private (Whereby a scan of the name registry does not reveal the human readable names).
I think 4 is a necessary property to mitigate CT log like reconnaissance feeds being used by threat actors to enumerate every registered identity for the purpose of automated attacks.
I wonder if something like this could follow the spirit of "tag" URIs where you include a temporal component. A semantics of "namespace Foo as established time T."
Any usage of the name in identifiers includes the epoch. Identifiers from several epochs could be concurrently in use. Identifiers rooted in different name epochs are not be comparable.
Out of band networking effects need to establish the meaning of a specific name epoch. The disambiguation doesn't work if the intended consumers are unwilling to learn and distinguish the epoch component of identifiers they care about.
I suppose, at the limit, this is the same as just having everyone add some numeric suffix to names they try to register? But it would be more constrained, e.g. structurally enforce that the digits correspond to some kind of clock metadata which is a witnessed and signed part of the decentralized ledger.
Thanks for putting this together. Found via Schneier’s blog; I thought it was a good summary, and perhaps needed information in the face of attacks like Chat Control.
Oh, I didn't realize it'd made it to Schneier's blog, thanks for letting me know!
A goal of the work was to try to explain to a new audience (specifically nontechnical legal folks) the ongoing challenges with Going Dark. Hopefully it helps!
The paper says ghost protocol has never been implemented, but wasn't it widely used on trump administration version of the signal-custom-client, which sent messages to a ghost account responsible for indexing and backup of plain text copies?
Good point. Most of this was written before the signal-custom-client thing happened, so it wasn't top of mind. We also considered "serious" systems, deployed en masse. Perhaps we should've included this as well.
I've been working on a project for the last six months that brings mTLS to the masses. Meaning, post-quantum end-to-end encryption with human readable identities. It uses a decentralized root of trust for, basically, a lot of the history this article covers.
Human readable identities are the hardest part (unless you just mean BIP-style word chains). What’s your approach look like? How do you prevent collisions?
You register a DNS-style name. Registrations lasts a year with a 3 month post-expiration window to reregister, otherwise it gets released back. The system goes out of its way to make name trading uneconomical - specifically to work against speculators and name-sitters from coming in and ruining things.
Ah, ok. Is there a fallback for using bare keys instead of human readable names? If not, you have just recreated a central gatekeeper problem; you could be ordered to terminate name service for someone. Unless it’s using some decentralized crypto system like eth.
Optional human readable names could be a good system combining convenience with resilience.
It's using a decentralized backend. No, it's not using any existing blockchain, nor does it have any tradable token. It does have some blockchain properties, but the main layer is built on top of libp2p.
Agreed it's a very hard problem. We're in the process of forming a syndicate of like-minded parties who are interested in seeing this come to life because the model itself has no exit plan and is basically anathema to traditional capital funding.
Also, to be clear, names are hashed/salted in the backend with Argon2ID and a rotating salt. So the name index itself isn't enumerable, but it doesn't necessarily guarantee names are private once they are shared publicly. Theoretically you could lookup someone based on their public key without knowing their name - so in that sense it's somewhat close to what you're describing.
Interesting. Yes, the possibility of direct key lookup would solve the problem, especially if existing contacts remain connected even after name expiration/revocation.
Perhaps you could do a name presale, although I’m not sure that would be enough funding. I look forward to hearing more about it.
We'll probably do a name presale, but this is deep tech/big infra we're setting up, so it wouldn't be enough. That's why we're busy partnering with like-minded individuals to do a non-traditional raise. We did start with the more traditional route, but all of them (including a16z) were baffled by our choice to not resort to degenerate behavior (i.e. a16z in particular refused to play game without making a token and listing it on a DEX).
Anyone interested can reach me directly at hn@sepositus.com (this is a SimpleLogin alias to protect my email from spam).
What two properties are you choosing from Zooko’s Triangle? You say human readable and decentralized, so you must be giving up secure.
A few things, Zookos conjecture dates to 2001. It was an observation, not a formal proof of anything, nor a physical limit, as he said in the paper: "I didn't prove that it is impossible to have all three features"
So without conflating Zooko with all the commentators who followed saying, "but Secure meant ...", lets look at the real definition from Zooko:
1. distributed (in the sense that there is no central authority which can control the namespace, which is the same as saying that the namespace spans trust boundaries), 2. secure (in the sense that name lookups cannot be forced to return incorrect values by an attacker, where the definition of "incorrect" is determined by some universal policy of name ownership), 3. and having human-usable keys.
So the system we are building (I am the architect) Satisfies all 3. I went and added a fourth, which is privacy. I say:
4. Private (Whereby a scan of the name registry does not reveal the human readable names).
I think 4 is a necessary property to mitigate CT log like reconnaissance feeds being used by threat actors to enumerate every registered identity for the purpose of automated attacks.
I wonder if something like this could follow the spirit of "tag" URIs where you include a temporal component. A semantics of "namespace Foo as established time T."
Any usage of the name in identifiers includes the epoch. Identifiers from several epochs could be concurrently in use. Identifiers rooted in different name epochs are not be comparable.
Out of band networking effects need to establish the meaning of a specific name epoch. The disambiguation doesn't work if the intended consumers are unwilling to learn and distinguish the epoch component of identifiers they care about.
I suppose, at the limit, this is the same as just having everyone add some numeric suffix to names they try to register? But it would be more constrained, e.g. structurally enforce that the digits correspond to some kind of clock metadata which is a witnessed and signed part of the decentralized ledger.
Coauthor here, somewhat surprised to see this on HN. Any thoughts, questions, or feedback welcome.
Thanks for putting this together. Found via Schneier’s blog; I thought it was a good summary, and perhaps needed information in the face of attacks like Chat Control.
Oh, I didn't realize it'd made it to Schneier's blog, thanks for letting me know!
A goal of the work was to try to explain to a new audience (specifically nontechnical legal folks) the ongoing challenges with Going Dark. Hopefully it helps!
The paper says ghost protocol has never been implemented, but wasn't it widely used on trump administration version of the signal-custom-client, which sent messages to a ghost account responsible for indexing and backup of plain text copies?
Good point. Most of this was written before the signal-custom-client thing happened, so it wasn't top of mind. We also considered "serious" systems, deployed en masse. Perhaps we should've included this as well.
Usenet and IRC over I2P.
“Everything is end-to-end encrypted… depending on how you define the ends.”
It is not great that they use the E2EE term to describe TLS, although it's for a good cause