On 26/03/14 16:54, Michael Rogers wrote:

Hi all,

(Please let me know if this belongs on tor-talk instead of here.)

I'm working on a messaging app that uses Tor hidden services to provide unlinkability (from the point of view of a network observer) between users and their contacts. Users know who their contacts are, so we don't need mutual anonymity, just unlinkability.

I wonder whether we need everything that the Tor hidden service protocol provides, or whether we might be able to save some bandwidth (for clients and the Tor network) and improve performance by using parts of the hidden service protocol in a different way.

First of all, we may not need to publish hidden service descriptors in the HS directory, because we have a way for clients to exchange static information such as HS public keys out-of-band.

Second, we may not need to use introduction points to protect services from DoS attacks - we can assume that users trust their contacts not to DoS them.

Third, we may be able to reduce the number of hops in the client-service circuits, because we don't need mutual anonymity.

This isn't the first app to use hidden services for unlinkability, so I expect this topic's come up before. Are there any discussions I should look at before coming up with hare-brained schemes to misuse the hidden service protocol?

Cheers, Michael

A further requirement, as I understand from a previous discussion with Michael, is that the app can't assume that each user has a publicly-accessible IP/port.

One idea (instead of using HS) is to simply have each user also be a normal (non-hidden) internet service, and have the contact connect to them through Tor. However, this doesn't address the IP/port issue. We could look into ICE as a NAT traversal technique, but it's far from clear whether this will work *through* Tor (i.e. to have the exit node run ICE with the contact).

So another possibility is using a HS-like system, where the rest of the network provides the listenable ports.

X