[prev in list] [next in list] [prev in thread] [next in thread]
List: tor-dev
Subject: Re: [tor-dev] Using the HS protocol for unlinkability only
From: Ximin Luo <infinity0 () torproject ! org>
Date: 2014-03-26 17:35:29
Message-ID: 53330FE1.2090205 () torproject ! org
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
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
["signature.asc" (application/pgp-signature)]
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic