Christopher Baines cbaines8@gmail.com writes:
On 10/10/13 23:28, Paul Syverson wrote:
On Wed, Oct 09, 2013 at 03:02:47PM +0100, Christopher Baines wrote:
On 09/10/13 11:41, Paul Syverson wrote:
> These two changes combined should help with the two goals. Reliability > is improved by having multiple OP's providing the service, and having > all of these accessible from the introduction points. Scalability is > also improved, as you are not limited to one OP (as described above, > currently you can also have +1 but only one will receive most of the > traffic, and fail over is slow).
Do you see any disadvantages to this design?
So, care needs to be taken around the interaction between the hidden service instances, and the introduction points. If each instance just makes one circuit, then this reveals the number of instances.
You said something similar in response to Nick, specifically you said
I believe that to mask the state and possibly number of instances, you would have to at least have some of the introduction points connecting to multiple instances.
I didn't understand why you said this in either place. Someone would have to know they had a complete list of introduction points to know the number of instances, but that would depend on how HS descriptors are created, stored, and distributed. From whom is this being hidden? You didn't state the adversary. Is it HS directory servers, intro point operators, potential clients of a hidden service? I don't see why any of these necessarily learns the state or number of instances simply because each intro point is chosen by a single instance (ignoring coincidental collisions if these choices are not coordinated).
To clarify, I was interpreting the goal as only the service operator should know the number of instances. In particular, the adversary here is the introduction point. If hidden service instances only ever create one circuit to each introduction point, each introduction point knows the number of instances of every service it is an introduction point for, as this is the same as the number of circuits for that service.
I'm missing something. Suppose there is a hidden service with ten instances, each of which runs its own introduction point. How do any of these ten introduction points know the number of instances because they each see a single circuit from the hidden service?
Ah, I have not been explicit enough when describing the behaviour I want to implement. In my original email, I set out that each instance of the service connects to each introduction point (this has also developed/changed a bit since that email). Unfortunately, I did not state the resultant behaviour I was looking to achieve (the above), just the changes to the protocol that would result in this behaviour.
That's from the PoV of Introduction Points. On the other hand, a client that knows the onion address of an HS (or an HSDir before https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html gets implemented) can still get the list of all IPs (at least with the current directory design). If some of the "HS peers" that correspond to those IPs are down, then a client can notice this by sending INTRODUCE1 cells to all the IPs and seeing which ones fail.
As a more conditional attack (from the IP PoV), let's think of a super-HS with two "HS peers" where each of them has one Introduction Point. If one of the "HS peers" goes down, then the other IP might be able to figure this out using the number of introduction it conducts (if we assume that each IP used to do half of the introductions of the HS, then the number of introductions will increase when one "HS peer" goes down.)