On 29/10/14 13:01, George Kadianakis wrote: > Christopher Baines <cbaines8@xxxxxxxxx> 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@xxxxxxxxxxxxxxx: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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev