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