[tor-dev] Potential projects for SponsorR (Hidden Services)

[Christopher Baines]

On 29/10/14 13:01, George Kadianakis wrote:
> Christopher Baines <cbaines8 at gmail.com> writes:
> 
>> On 20/10/14 14:37, George Kadianakis wrote:
>>> f) On a more researchy tone, this might also be a good point to start
>>>    poking at the HS scalability project since it will really affect HS
>>>    performance.
>>>
>>>    We should look at Christopher Baines' ideas and write a Tor
>>>    proposal out of them:
>>>    https://lists.torproject.org/pipermail/tor-dev/2014-April/006788.html
>>>    https://lists.torproject.org/pipermail/tor-dev/2014-May/006812.html
>>>    Last time I looked, Christopher's ideas required implementing
>>>    proposal225 and #8239.
>>
>> I am still around, and interested in helping out with this! :)
>>
> 
> Hello,
> 
> glad to see you are still interested in this.

Apologies for the very late reply. My project report is now available
here, it probably covers some stuff that is relevant to the project, and
lots of stuff that is not relevant [1].

1: http://cbaines.net/projects/tor/disths/report.pdf

> I think the first step here is to write a document with the various
> solutions, their requirements, and how they influence the threat
> model.

I do this in the report, without much depth though.

> First of all, what do we mean by scalability and what properties are
> we trying to offer?

So, I looked at distribution (removing bottlenecks), but never showed
that this was a problem for scalability, or that anything I did improved
the scalability.

With that in mind, here are the goals I looked at.

Primary Goals

Allow for the distribution of connections to a hidden service. This is
the core goal, as achieving this would allow for the horizontal scaling
(scaling through adding nodes to the system) of hidden services, by
distributing the load across multiple machines.

A service must be accessible if one or more instances are in operation.
In conjunction with the previous goal, this provides a means for
achieving increased availability, the service can be hosted from
multiple geographical locations, reducing the probability of all of the
service instances going oine (e.g. due to power or network outage).

Secondary Goals

Obscure the number of hidden service instances. The number of instances
needs only to be known to the hidden service operator.

Obscure the state of each service instance. The state (operational or
not) service instance can help to compromise the anonymity offered by a
hidden service if available.

> On concrete schemes now, what features are needed to implement your
> scheme [0]?  Can these requirements be changed? For example, on the
> topic of selecting IPs, can we dump the requirement for global
> randomness, by using the long-term private key as a seed to picking
> IPs?

This is covered in the report. In short:
 - Remove the restriction on connections to an Introduction Point
 - Remove Introduction Point Specific Keys
 - Use one to many circuits when passing Introduction Requests
 - Bootstrap Service via Initial Descriptor Check
 - Introduction Point Instance Selection
 - Selecting New Introduction Points
 - Introduction Point Reconnection

All of these things I implemented (to some degree) for testing (disths
branch of git at git.cbaines.net:tor).

As for the global randomness issue, I see no reason why using the
private key would not work, but don't know enough to say it will.

> Also, what's the threat model of your scheme? What more information do
> the IPs learn? What more information do the clients learn?

In the way that I implemented it, introduction points are able to
determine the state and number of hidden service instances.

I think this could be helped if each service instance connected to each
introduction point via 1 to n circuits, each circuit looks identical, so
this means that instead of knowing the exact number, you just know that
it is <= n. By closing these circuits as part of the normal operation of
the hidden service, I think you could also mask instance failure.

This approach might however make it easier to locate instances, due to
multiple circuits being used.

> What other ways are there to do HS scalability? How does their threat
> model change [1]? etc.

I cover a few ways of doing distribution in the report.

> By the way, is your thesis somewhere public? I imagine that it tackles
> a few of these questions already.

See above.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141115/8a67d390/attachment.sig>