Re: [tor-dev] "Trawling for Tor Hidden Services: Detection, [...]"
Hi,
I'm still pretty sure this only makes people more secure in theory; the basis appears to be that instead of connecting to a random node every time a circuit is built, you instead connect to only one entry/guard node for 30-60 days. I think on paper that reduces the probability, but it seems to presume an attacker that doesn't modify their attack and doesn't appear to account for a keyspace of sorts that has reduced by over 50% and the introduction of a "touch me here" flag that says you're not only a relay, but you're guaranteed to be an entry point relay. Looking at the numbers from a snapshot a few days ago: 839 exits, 865 guards, 1676 generic relays. Previously for entry you'd be looking at a 'keyspace' of n/(839+865+1676), with the obvious problem that connecting to them at random every time you create a circuit is going to increase the probability that you hop through a compromised node. However, you need a fairly large value of N to make that realistic, I think the number cited was approaching 50%, but I could be remembering that incorrectly. Now, you're at 865 _guaranteed_ entry points, which automatically reduces the required value for N and increases the value of each rogue node that gains the guard flag, which appears to be strictly based on bandwidth and stability. I'm hardly an expert on math or probability, but it seems like the 'weight' so to speak of a compromised node was never increased to account for the reduced number of nodes or guarantee that being a guard will always yield entry point traffic, which is to say that N is actually going to be some value multiplied by N instead of just N/C^2, (N*nWeight/C or possibly even N^nWeight/C). It at least seems like the probabilities were only worked for the state the network was in, and not for the state/behavior of the network after the modifications. So now you have a network where one can setup two boxes that are fast and stable and be guaranteed to receive exit and entry traffic and only needing about half as many boxes to reach the same 50% mark as before. The math behind this concept is not overly compelling or I'm just dumb, both are probable and neither are mutually exclusive, but if I were looking for a state-based backdoor, I'd imagine it to look a bit like this (which is not to imply that is the case here by any means). Jon On Thu, May 23, 2013 at 11:35 PM, <tor-dev-request@lists.torproject.org> wrote:
On Fri, May 24, 2013 at 12:32:20AM -0400, Jon Smithe wrote:
Hi Jon! You make some interesting and valid points, however this is the type of statement that spreads fud and it doesn't help anyone. Please see bug #8240 [0] which contains a detailed discussion of this topic. tl;dr This is being worked on, 0.2.4 addresses many of these problems and 0.2.5 will continue to make improvments. Whether or not you were implying this situation was a calculated decision that resulted in a "state-based backdoor", it is the insinuation of such a thing that can hurt Tor's reputation. - Matt [0] https://trac.torproject.org/projects/tor/ticket/8240
participants (2)
-
Jon Smithe -
Matthew Finkel