Idea: Exploration of possible cwtch identifiers #91

Closed
opened 2018-07-17 16:35:28 +00:00 by Wheest · 5 comments

Hey there folks,

I had a look at ricochet last year, and read the whitepaper for cwtch a couple of weeks back.

One of the open problems was "Usability of Cwtch Identifiers".

I haven't used golang for a project before, so haven't been able work out how to build the codebase from source yet.

However, I did put together this document discussing some of the ways an identifier could be represented to users, along with a PoC in Python. I haven't seen any identifiers particular to cwtch yet, so I just compared Richochet, and what I think is onionv3 addresses. I assumed that both were encoded in base36.

Anyway, any feedback or suggestions would be appreciated. Especially since I haven't had the chance to use cwtch myself yet.

(Github) Mnemonic - Base64 strings as human readable phrases

Thanks,
Wheest

Hey there folks, I had a look at ricochet last year, and read the whitepaper for cwtch a couple of weeks back. One of the open problems was "Usability of Cwtch Identifiers". I haven't used golang for a project before, so haven't been able work out how to build the codebase from source yet. However, I did put together this document discussing some of the ways an identifier could be represented to users, along with a PoC in Python. I haven't seen any identifiers particular to cwtch yet, so I just compared Richochet, and what I think is onionv3 addresses. I assumed that both were encoded in base36. Anyway, any feedback or suggestions would be appreciated. Especially since I haven't had the chance to use cwtch myself yet. [(Github) Mnemonic](https://github.com/Wheest/mnemonic) - Base64 strings as human readable phrases Thanks, Wheest
Owner

Hi!

Yeah this is one of those questions that eats at me - I actually played around with a similar word-list based approach a few years ago (https://github.com/ricochet-im/ricochet/issues/128#issuecomment-107001948)

There are a few formats we've been using for Cwtch:

  • raw torv2 / ricochet address e.g. cwtch:53gt5ixjrfzoik5i
  • username@cwtch e.g sarah@53gt5ixjrfzoik5i
  • group@server F4E6C722947A997C....@ogyogoytizc7jrzv

Cwtch will almost-definitely use torv3 addresses which even with word list encoding become unwieldy and we are going to need a more friendly approach.

My leaning right now is to build a name-resolution cwtch bot that allows registration/lookup of names and package that with the software. This is a centralized approach, and one I don't like completely, but I think we could design it in such a way that trust/metadata is minimized as far as possible and make it optional - it certainly needs thinking through.

The other approach, as you noted, is a blockchain/namecoin type approach which I don't think works well for Cwtch given the metadata resistant goals.

Hi! Yeah this is one of those questions that eats at me - I actually played around with a similar word-list based approach a few years ago (https://github.com/ricochet-im/ricochet/issues/128#issuecomment-107001948) There are a few formats we've been using for Cwtch: * raw torv2 / ricochet address e.g. cwtch:53gt5ixjrfzoik5i * username@cwtch e.g sarah@53gt5ixjrfzoik5i * group@server F4E6C722947A997C....@ogyogoytizc7jrzv Cwtch will almost-definitely use torv3 addresses which even with word list encoding become unwieldy and we are going to need a more friendly approach. My leaning right now is to build a name-resolution cwtch bot that allows registration/lookup of names and package that with the software. This is a centralized approach, and one I don't like completely, but I think we could design it in such a way that trust/metadata is minimized as far as possible and make it optional - it certainly needs thinking through. The other approach, as you noted, is a blockchain/namecoin type approach which I don't think works well for Cwtch given the metadata resistant goals.
Author

Glad to see that the space has been explored before. The extension of applying the encoding in chunks, with different word lists chosen from each time to make a more meaningful sentence is really novel. Something I'll keep thinking about for a while. Standardised, it could be a great way of having memorable secrets (though I'm not a cognition expert, maybe people are better at remembering random looking strings than I realise).

In terms of name registration/lookup, two questions I can think of right now.

Setting the scene first of all, say that we have a user Alice with a onionv3 address at 4rkafskjfk..., and they want a more memorable name for this service, say they choose the name cauldhame. Alice sends this tuple of 4rkafskjfk... and cauldhame to the name registration bot which propagates it through cwtch name servers (let's assume the address is transparent for now).

If Bob is given the name cauldhame, to find Alice's true address, they need to put in a request with a name server, who should return 4rkafskjfk....

So, assuming this scenario is roughly what you're thinking:

  • How "secret" should onionv3 addresses be from name server operators? Having a globally poll-able list of hidden services seems to defeat the purpose

This could be mitigated by having a name, and a "join code". So the name server has the name cauldhame, and the address encrypted using some scheme with a join code such as 24hpii94fw81.... So the server stores (name, E(join_code, address)). The address is decrypted locally by Bob after fetching. This method does have the downside anyone who knows the join code can populate name servers with misleading addresses associated with cauldhame. I guess that brings me on to my second question:

  • What kind of authentication would there be that the address resolved from a name is actually the address of the entity that you want?
Glad to see that the space has been explored before. The extension of applying the encoding in chunks, with different word lists chosen from each time to make a more meaningful sentence is really novel. Something I'll keep thinking about for a while. Standardised, it could be a great way of having memorable secrets (though I'm not a cognition expert, maybe people are better at remembering random looking strings than I realise). In terms of name registration/lookup, two questions I can think of right now. Setting the scene first of all, say that we have a user Alice with a onionv3 address at `4rkafskjfk...`, and they want a more memorable name for this service, say they choose the name `cauldhame`. Alice sends this tuple of `4rkafskjfk...` and `cauldhame` to the name registration bot which propagates it through cwtch name servers (let's assume the address is transparent for now). If Bob is given the name `cauldhame`, to find Alice's true address, they need to put in a request with a name server, who should return `4rkafskjfk...`. So, assuming this scenario is roughly what you're thinking: - How "secret" should onionv3 addresses be from name server operators? Having a globally poll-able list of hidden services seems to defeat the purpose This could be mitigated by having a name, and a "join code". So the name server has the name `cauldhame`, and the address encrypted using some scheme with a join code such as `24hpii94fw81...`. So the server stores `(name, E(join_code, address))`. The address is decrypted locally by Bob after fetching. This method does have the downside anyone who knows the join code can populate name servers with misleading addresses associated with `cauldhame`. I guess that brings me on to my second question: - What kind of authentication would there be that the address resolved from a name is actually the address of the entity that you want?

Okay so some thoughts on this that I've been failing to actually say for like a month plus because I'm a disaster at doing anything:

I think it might work to have a cellphone-contacts type model? Like, where we have globally-unique addresses that are not all that human memorable/distinguishable, stored locally-to-the-person with info like Contact Name and stuff.

Adding new contacts like that could be done by relatively-carefully-reading the long unweildy identifier*, but only once.

Groups (and servers? Do we want to do that?) could be handled similarly, just labeled in the lists as Groups, not people.

Within a group conversation, to (a) allow people you haven't met to have readable names, and (b) allow all the fun name-hopping-for-specific-jokes-and-stuff we've come to expect (and equivalently (c) be conducive to people trying out different names/identities/that Personal stuff) could display the display-name they use for the group, and then (slightly less emphasized) the unique-to-the-current-viewer name -- that would either be the name in their contacts list, if they have them, or else their cwtch id, truncated until it's unique to the current group.

e.g.:

sarah (Sarah Jamie Lewis): something something
gaditb (cwtch:dslkjgdlgf...): something else mumble mumble
The Great Houndini (cousin Rachel from New York): stuff

(As, like, a quick thoughtsketch. There are prolly better ways to display it.)

* This could probably be improved by using the word-ist method as a transport protocol. That makes it easier to read/hear out loud, type, and remember for the few seconds it takes to write it down. Additionally because this is a transport protocol negotiated between humans just for that one transmission, it has the advantage that we can allow for multiple wordlists, so that we can easily add other languages (possibly just copying the Diceware Word Lists and not start with non-English-as-second-class (although we may want to do different word lists to emphasize sound differences).

We could even have a similar way of doing visual transport/confirmation views, allowing for an easy way to pass them as QR-codes, unique pictures like SSH does, etc.

Okay so some thoughts on this that I've been failing to actually say for like a month plus because I'm a disaster at doing anything: I think it might work to have a cellphone-contacts type model? Like, where we have globally-unique addresses that are not all that human memorable/distinguishable, stored locally-to-the-person with info like Contact Name and stuff. Adding new contacts like that could be done by relatively-carefully-reading the long unweildy identifier\*, but only **once**. Groups (and servers? Do we want to do that?) could be handled similarly, just labeled in the lists as Groups, not people. Within a group conversation, to (a) allow people you haven't met to have readable names, and (b) allow all the fun name-hopping-for-specific-jokes-and-stuff we've come to expect (and equivalently (c) be conducive to people trying out different names/identities/that Personal stuff) could display the display-name they use for the group, and then (slightly less emphasized) the unique-to-the-current-viewer name -- that would either be the name in their contacts list, if they have them, or else their cwtch id, truncated until it's unique to the current group. e.g.: >sarah (Sarah Jamie Lewis): something something >gaditb (cwtch:dslkjgdlgf...): something else mumble mumble >The Great Houndini (cousin Rachel from New York): stuff (As, like, a quick thoughtsketch. There are prolly better ways to display it.) \* This could probably be improved by using the word-ist method *as a transport protocol*. That makes it easier to read/hear out loud, type, and remember for the few seconds it takes to write it down. Additionally because this is a transport protocol negotiated between humans just for that one transmission, it has the advantage that we can allow for multiple wordlists, so that we can easily add other languages (possibly just copying the [Diceware Word Lists]( https://theworld.com/~reinhold/diceware.html#Diceware%20in%20Other%20Languages|outline ) and not start with non-English-as-second-class (although we may want to do different word lists to emphasize sound differences). We could even have a similar way of doing visual transport/confirmation views, allowing for an easy way to pass them as QR-codes, unique pictures like SSH does, etc.
Author

The cellphone-contacts model is what I imagine the default set of affairs might be. Additionally, as you suggest, there could be a specific message header that gives someone an in-group nickname of their choice.

What I see as the design problem here is how can you have a way sharing these long Torv3 addresses in a more user friendly way, without compromising security. I too have been thinking about it, with some half baked methods of storing a global list of usernames, with users sharing their username, and a random "join code" key, and servers storing a key/value pair with the username and an address encrypted with the join-code. But then there are all of the issues of how many bits one would need for a good join-code, and the biggie of authenticity. Plus there is the global state coordination headache.

I'm still trying to strengthen my understanding of crytpoprimites, so I can't say for sure if there's a place for a zk-proof here. Conceptually, the "Where's Waldo Book" behind a big bit of paper with a hole in it is all I can grasp conceptually rn. If anyone has any comments on this, it would be appreciated.

But I think that we should probably be clearer about what our user models are here. How would our users be sharing their cwtch addresses anyway? If it's over an existing digital channel, then we can just copypaste. If it's verbally, or some other method that requires manual typing, then we've got a problem. Perhaps QR codes are how most folk would use it? If people are using the long-form addresses, it's difficult to remember, and error prone to type.

Would it make sense to create say 3 model users to aid the design process? Who would we interview for that?

The cellphone-contacts model is what I imagine the default set of affairs might be. Additionally, as you suggest, there could be a specific message header that gives someone an in-group nickname of their choice. What I see as the design problem here is how can you have a way sharing these long Torv3 addresses in a more user friendly way, without compromising security. I too have been thinking about it, with some half baked methods of storing a global list of usernames, with users sharing their username, and a random "join code" key, and servers storing a key/value pair with the username and an address encrypted with the join-code. But then there are all of the issues of how many bits one would need for a good join-code, and the biggie of authenticity. Plus there is the global state coordination headache. I'm still trying to strengthen my understanding of crytpoprimites, so I can't say for sure if there's a place for a zk-proof here. Conceptually, the "Where's Waldo Book" behind a big bit of paper with a hole in it is all I can grasp conceptually rn. If anyone has any comments on this, it would be appreciated. But I think that we should probably be clearer about what our user models are here. How would our users be sharing their cwtch addresses anyway? If it's over an existing digital channel, then we can just copypaste. If it's verbally, or some other method that requires manual typing, then we've got a problem. Perhaps QR codes are how most folk would use it? If people are using the long-form addresses, it's difficult to remember, and error prone to type. Would it make sense to create say 3 model users to aid the design process? Who would we interview for that?
Owner

Closing in favour of cwtch.im/cwtch-ui#415 which is likely the main improvement to sharing cwtch identifiers.

Closing in favour of https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/415 which is likely the main improvement to sharing cwtch identifiers.
sarah closed this issue 2022-07-05 23:30:46 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cwtch.im/cwtch#91
No description provided.