Iván Pazmiño <ipazmino@thoughtworks.com> writes:

Hello, thanks for your reply.

On 02/04/2016 04:28 PM, George Kadianakis wrote:

...

We don't actually and it's a pity because it would have been very useful for this particular case indeed. We will write one then.

Exciting!

...

However, the entry guard code in Tor is not particularly clean or well abstracted. So finding the underlying algorithm will not be a trivial task. That's also another reason we are trying to move to a more formalized algorithm, so that it's more easily studied.

We've started looking at the code and so far we believe the relevant scenarios would be those when you invoke choose_random_entry_impl with a NULL state. Would that be correct?

I _think_ that also the non-NULL state scenario is relevant. choose_random_entry_impl() is called with an initialized state in onion_extend_cpath(). That's the codepath when "we are building a circuit and we need an entry guard for it". choose_random_entry_impl() is called with a NULL state in add_an_entry_guard(). That's the codepath for "shit we are out of entry guards. We need a new one." I think both of these codepaths are relevant. Maybe to make sure, add some logging calls in choose_random_entry_impl() and start up your Tor, to see if it's called with a NULL state or not.

Cheers, Iván