Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Human-readable identifiers #184

Open
yanmaani opened this issue Feb 29, 2024 · 1 comment
Open

Human-readable identifiers #184

yanmaani opened this issue Feb 29, 2024 · 1 comment

Comments

@yanmaani
Copy link

yanmaani commented Feb 29, 2024

Ricochet-refresh relies on v3 onions to uniquely identify contacts. This is secure, but not human-readable.

Within Tor, there is a specification for pluggable naming systems (proposal 279). A client to the tor daemon keeps a mapping of (TLD -> executable), then looks up queries for the known TLDs using the executable file specified in its configuration.

The direct application of proposal 279 to RR would not be a good fit for its security model - it would be as if, in Signal, you could randomly have the key for a contact changed from beneath your feet. However, having ricochet act as the proposal 279 client would (to me) make perfect sense.

Basically: When trying to add a contact, currently, Ricochet-refresh could (alongside ricochet:) also support other prefixes. Then, if a query is made matching one of those prefixes, it would be redirected to the appropriate service.

I propose to implement this by adding a new tab to the settings called "ID systems" or "naming", where the user can define which services to use (i.e. nameid: -> /path/to/namecoin.shim). Ricochet would query these services immediately upon trying to add the contact and turn it into an onion, which would be the only identifier stored durably. Then, if one or more services turn out to be both secure and easy to use, they could be officially integrated into Ricochet.

@morganava
Copy link
Collaborator

morganava commented Mar 7, 2024

Indeed, prop 279 if i understand correctly is only a proposal and not actually implemented in the tor daemon.

So the fundamental problem here can be summarised by Zooko's Triangle

image

tldr: human-meaningful, decentralised, and secure; pick 2

onion service-ids (and by extension ricochet-ids) focused on decentralised and secure. I won't pretend to fully understand all of the parts of onion service system, but onion service-ids are a representation of the cryptographic public key of the cryptographic private key used to hand waving somehow register the onion service in the tor network.

Prop 279 basically comes in and says ok lets make a system that allows us to in someway solve the human meaningful problem at the detriment of the other two, in whatever way that makes sense for an application.

So, the current situation for some aspects of usability isn't great, but given Ricochet-Refresh's chosen audience/target demographic is journalists+whistleblowers, activists and the like, I think being cautious here is wise.

side-note: we should do some user-research and actually figure out what our users are using Ricochet-Refresh for in some sense

I don't particularly like the idea of adding a plugin-system or shim system to Ricochet-Refresh given both the security+privacy implications and the kind of shit-show we have now around the pluggable transports ecosystem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants