On Sat, Jul 18, 2015 at 03:11:26AM +0300, s7r wrote: > I still see the third hop (speaking from hidden service server start > point) is the weak part here. An attacker can connect to a hidden > service at his malicious relay selected as rendezvous. Before you know > it, all relays in third_guard_set are enumerated by the attacker. This > is why I think it's better to have a bigger value for NUM_THIRD_GUARDS > and a shorter period for THIRD_GUARD_ROTATION.
I haven't been keeping up with this thread well, so maybe that has already been mentioned, but in case it hasn't: also consider the case where the Tor client runs two hidden services, and so they share the same guard infrastructure. In today's design, they each have one guard, but many Tor clients have that one guard, so you can't conclude much from noticing it. In last year's design, they each have the same three guards, which is a nearly unique fingerprint. In the above design, where we have more third-level guards, we're heading back into the unique fingerprint territory. So many constraints to consider at once! :) --Roger _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
