Re: [tor-dev] Questions pertaining to client to directory authority

Hello, I receive a daily digest, so I am replying to everything at once.
Well look at that, thank you. That's what I get for skimming a bit too much.
As pointed out above, I missed some things while reading the specifications, I hadn't quite made it to the bottom of the 3rd version of the directory spec, which is where all the URIs are and is largely what I was looking for. Piecing together all of the URIs and their exact contexts through the code was proving to be daunting, although surprisingly I got most of what I was looking for correctly. Either way, assuming I feel like I understand things well enough to explain them at some point, I would think at least throwing together some type of flow diagram would be fairly painless and I imagine others would indeed benefit from it. For anyone reading this in the interim, I actually found starting with the v1 specification and working towards the v3 was beneficial. I imagine a lot is outdated, but it somehow managed to make me take note of other things I had missed in the v3 spec.
Aha, so I imagine with moria1 the issue is that I'm connecting directly to port 9131 instead of tunneling it through the ORPort. I just retested to make sure I hadn't lost my mind and indeed directly connecting to port 9131 eventually just returns a single byte ('\0'). This seems to be the case with turtles as well, however the other authorities that serve the dirport over the traditional HTTP port (80) seem to not have this authentication/DPI evasion behavior.
I suspected that might be the case. Thanks for the answer.
I can imagine you've had a few headaches over the lifetime of the project :)
Indeed you are correct, I must have gotten the lines crossed while reading them somewhere and mixed it up with another of the authorities. Either way, despite my criss-cross, my hinting suspicion was correct: trying to speak v2 to v3 servers (off-hand I'm not positive which authority I was connected to when I tested/wrote that)
Indeed, I spoke too soon
But see also https://trac.torproject.org/projects/tor/ticket/7106
I will be mindful of this as I progress, it's quite evident by all of the various measurements tor takes that there is a lot of care in the behavior of the various components. .
Well I was more assuming that any adversary that could inject enough guard nodes would also be able to inject 'enough' exit nodes, as my understanding is that this is an actual flag they control directly.
I agree that the guard notion is counterintuitive, and also it's not perfect, but I think it's way better than not doing it.
I've not had a chance to read the links you provided, so I am still speaking from my relatively feeble comprehension, but essentially it seems like the guards more or less condense the number of entry points to the network? Whereas there are thousands of potential relays that could be used as an entry point, there is about a thousand guard nodes. So, and again I am probably not entirely comprehending something, but it seems that we've just made the requisite value for C smaller? (Again assuming that anyone who could get a large volume of relays of any kind could reasonably also control a large volume of exit nodes)
Will do, thanks!
1 guard is better than 3 guards in this respect. But both 1 and 3 are way better than 0.
While I agree with this notion, I guess what I am asking is: 'are 3 guard nodes better than X generic entry nodes for values of X that are significantly larger than 3' (pure example. obviously there is more than 3 guard nodes). As I'm understanding things, the concept was introduced to combat the problem discussed in path-spec.txt section 5 (C/N^2), but it seems like the introduction of guard nodes, because there are so much fewer of them than regular relays and because they are guaranteed to be an entry point into the network in essence just makes the value of N smaller and thus the number of C required to mount at least half of the attack smaller. More over it also removes the 'guess work' as intermediate relays between the guard and exit more or less become irrelevant? Rephrased, does converting the problem to C/N instead of C/N^2 still hold true if in the process we make the values of N and thus C significantly smaller, at what point does C/N^2 present a better probability? I'll read more, I am obviously missing something. Thanks a lot for the links and information. Jon
participants (1)
-
Jon Smithe