Low priority: generate as many IDs as user asks

[hsribei]

Instead of having only one onion address that one can copy to give out to contacts, there could be an option to do like in Bitcoin wallets, where you can generate a new one for each contact (or reuse each address as often as you want) and have all transactions (in Ricochet's case, all buddies) on the same list.

That would allow using Ricochet for anonymous posts to web boards and forums, for example, or Craigslist (although it should be balanced against the off chance of one hidden service influencing the perceived bandwidth of the other and thus being correlatable, which might be a much smaller threat than tying everything to a single handle).

[hsribei]

I thought of this because one might want to create a "ricoID" for each tor relay they run and use it as its Nickname field, so people can anonymously get in touch with them about the relay without being able to tie them all to a single person or, worse yet, tie them all to the user's more stable and publicly announced handle.

[special]

See #52 for a prerequisite pile of research. I do have some neat ideas UI-wise on how this could work.

[hsribei]

Yeah, if you want them to be truly unlinkable there might be some hurdles.

But if you consider that, in the worst case, they are compromised and mapped back to one address, which is the best we've got so far anyway, I think it's all profit from there. Edit: ok, assuming that it doesn't get worse than linking back to one address and actually helps deanonimize you completely.

If you're careful not to promise network-level unlinkability, having "name-level" unlinkability is already a great boost in privacy.

[special]

I agree that there is a lot of value in having multiple names/identities.

The UI would need to clearly separate these names, and make it obvious to the user which name they're acting under. Contacts would probably be separated into groups based on which name/identity they're attached to. It could be possible to control availability for each of those groups independently.

Defining a threat model is tricky. We have to assume it will always be relatively easy for an adversary that can observe two hidden services to determine that they're published by the same entity. It's challenging to communicate that to the user - who would probably assume that their two identities are completely unlinkable.

I'm also concerned about having users publishing and maintaining several hidden services when they come online. It's a lot of traffic, a lot of circuits, and a lot of relays.

I think we should work in this direction, and spend more time thinking about the implications here. I'm thinking about a roadmap like:

1. Migrate to a client-authorized service to prevent HSDir enumeration & allow revocation
2. Allow contact requests on a different service than the one used for real traffic
3. Allow multiple contact request addresses, including one-time-use addresses
4. Allow actually separate identities for contacts

Note that steps 2/3 move away from having a single address as a permanent identifier. I'd like to treat it as a piece of information exchanged for contact requests, and as an implementation detail - not something users are looking at or comparing.

[hsribei]

Note that steps 2/3 move away from having a single address as a permanent identifier. I'd like to treat it as a piece of information exchanged for contact requests, and as an implementation detail - not something users are looking at or comparing.

Having the hidden service address as a permanent identifiers relieves users from having an additional step of verifying key fingerprints, and that's a big relief. Would steps 2-3 require additional verification?

Also, what's the propagation time for a new hidden service address? Can it be trusted to start resolving as soon as I've published it?

[special]

Having the hidden service address as a permanent identifiers relieves users from having an additional step of verifying key fingerprints, and that's a big relief. Would steps 2-3 require additional verification?

No. I'll elaborate a bit.

1. Allow contact requests on a different service than the one used for real traffic

This would mean that your client publishes aaaaaaaaaaaaaaaa.onion to accept contact requests, and separately publishes bbbbbbbbbbbbbbbb.onion for connections from approved contacts. The benefit is that the user can disable contact requests and all traffic from unapproved contacts at will.

1. Allow multiple contact request addresses, including one-time-use addresses

This is more vague. The idea is that the user can create and destroy addresses for accepting contact requests. If I started getting spam and abuse via contact requests, I could switch to a new address without impacting my existing contacts. If I don't like having a public service at all, I could create single-use addresses that I only give out directly to people whom I want to have contact me.

That is only about contact requests, so it's important to communicate to the user that they are not creating separate identities for anyone they accept as a contact.

So what I meant with "permanent identifier" is that these steps are moving away from having a single, canonical address that you can compare and use to refer to a person, similar to a key fingerprint. I don't think they would add any more burden on the user.

But these are half-formed thoughts, there are a lot of open questions and problems.

Also, what's the propagation time for a new hidden service address? Can it be trusted to start resolving as soon as I've published it?

In practice with current tor, it's under 30 seconds. That may technically be a 'bug' - there is supposed to be a delay. In general, Ricochet depends on being able to publish and connect to a new service within a few minutes.