Initialize the SOCKS password to random offset at start

When Tor Browser starts, the SOCKS password is initialized to 0. Each time a new circuit is to be used, it is incremented. Unfortunately, if the browser is restarted, it is reset to 0, and it may cause the browser to re-use the same circuits. This is obviously bad for linkability. A workaround for this would be to randomize the SOCKS password to a random offset when Tor Browser starts up, so it is never initialized with a previously used password and thus previously used circuit.

added component::applications/tor browser owner::tbb-team priority::medium resolution::wontfix severity::normal status::closed type::enhancement labels

I was the one who suggested the random offset approach -- like other crypto protocols do it. I'm open to hearing an even better idea though.

(Another nice side effect of initializing it to a random number is that something that later breaks in and learns the number can't discover how many times it's been incremented. Not a big deal but a nice side effect.)

Trac:
Description: When Tor Browser starts, the SOCKS password is initialized to 0. Each time a new circuit is to be used, it is incremented. Unfortunately, if the browser is restarted, it is reset to 0, and it may cause the browser to re-use the same circuits. This is obviously bad for likability. A workaround for this would be to randomize the SOCKS password to a random offset when Tor Browser starts up, so it is never initialized with a previously used password and thus previously used circuit.

to

When Tor Browser starts, the SOCKS password is initialized to 0. Each time a new circuit is to be used, it is incremented. Unfortunately, if the browser is restarted, it is reset to 0, and it may cause the browser to re-use the same circuits. This is obviously bad for linkability. A workaround for this would be to randomize the SOCKS password to a random offset when Tor Browser starts up, so it is never initialized with a previously used password and thus previously used circuit.

My idea was a more naive "just randomize every single SOCKS password". Randomizing it sounds more elegant.

Perhaps, instead of initializing to a random offset, it could be initialized to the amount of microseconds since the epoch? That would ensure that it's constantly growing, so it would never initialize to a number lower than it was before (which could lead to re-using the same password).

Also, I believe this is the file which will need to be changed: https://gitweb.torproject.org/torbutton.git/tree/src/components/domain-isolator.js#n72

What if multiple requests are issued in the same microsecond (modulo timer resolution)?

The default behavior is "if Tor Browser restarts, so does tor", since Tor Browser is responsible for spawning and launching the tor instance. I filed #18125 (moved) with the same sort of thinking a while ago for addressing some of the more exotic situations.

Replying to yawning:

The default behavior is "if Tor Browser restarts, so does tor", since Tor Browser is responsible for spawning and launching the tor instance. I filed #18125 (moved) with the same sort of thinking a while ago for addressing some of the more exotic situations.

Wouldn't that require ControlPort access? A lot of people have that disabled when TOR_SKIP_LAUNCH is set so NEWNYM will never be received. It seems like something like this where the password is randomized would be better (maybe it should only be randomized if TOR_SKIP_LAUNCH is set).

Replying to cypherpunks:

(maybe it should only be randomized if TOR_SKIP_LAUNCH is set).

For all sorts of reasons, if we do this, we should do it for all cases. :)

Closed on behalf of #19206 (moved).

Trac:
Resolution: N/A to wontfix
Status: new to closed

closed

moved to tpo/applications/tor-browser#18787 (closed)