[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Using the HS protocol for unlinkability only



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

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev