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. > Also, in your response to Nick you said that not having instances share > intro points in some way would place an upper bound on the number of > instances. True, but if the number of available intro points >> likely > number of instances, this is a nonissue. I don't really follow your reasoning. > And come to think of it, > not true: if the instances are sometimes choosing the same intro points > then this does not bound the number of instances possible (ignoring > the number of HSes or instances for which a single intro point can > serve as intro point at one time). Ok, but I was assuming the current behaviour of Tor, which I believe prevents instances using some of the same introduction points. > Also, above you said "If each instance just makes one circuit". Did > you mean if there is a single intro point per instance? No, as you could have one instance that makes say 3 circuits to just one introduction point. This can help, as it can hide the number of instances from the introduction point. > Hard to say specifically without exploring more, but in general I > would be more worried about what is revealed because circuits are > built to common intro points by different instances and the intro > points can recognize and manage these, e.g., dropping redundant ones > than I would be because the number of intro points puts an upper > bound on instances. I don't quite understand the last part, but regarding introduction points handling more that one circuit for the same service. I think that having this helps possibly hide information (like the number of instances). This does depend on also allowing one instance to use multiple circuits, otherwise, some information would be given away. I might try creating a wiki page on the Tor wiki to collect all of the information in this thread, as it might be a nice reference for discussion.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev