Low entropy PRNG usage in Tor Browser?

We should look for places where Tor Browser may leak the state of a low-entropy PRNG, thus linking a user across sites. Math.random() is a possibility. (I haven't investigated yet.)

added component::applications/tor browser owner::tbb-team priority::medium severity::normal status::needs-information tbb-linkability type::defect labels

For Math.random(), it appears a separate PRNG state is initialized for each JS context. So, unless I am missing something, it appears that separate sites cannot be linked through PRNG state.

However, the Math.random() state is initialized with the local time in microseconds, which is very low entropy. Soeder et al showed that it is possible to run the PRNG in reverse (see section 4.2.2). So it should be relatively easy to extract the local time from Math.random(). If we want to hide the local clock skew, it will be necessary to change Math.random() to a high-entropy (non clock-based) source.

Trac:
Cc: N/A to gk

https://bugzilla.mozilla.org/show_bug.cgi?id=322529 has a long rambling discussion on this, and no patch.

To alleviate tracking concerns the seed needs to be changed. To make the world a better place, the algorithm could be replaced with something sensible as well (Just replacing the algorithm is insufficient to prevent the bad guys from making an educated guess about the clock, even if the algorithm has backtracking resistance).

Replying to yawning:

https://bugzilla.mozilla.org/show_bug.cgi?id=322529 has a long rambling discussion on this, and no patch.

To alleviate tracking concerns the seed needs to be changed. To make the world a better place, the algorithm could be replaced with something sensible as well (Just replacing the algorithm is insufficient to prevent the bad guys from making an educated guess about the clock, even if the algorithm has backtracking resistance).

Thanks for making this point and for the link. One possibility would be to use the '@mozilla.org/security/random-generator;1' (which is used to implement window.crypto.getRandomValues()), either as the seed alone or to replace both the seed and the algorithm. I don't know what the downsides might be -- perhaps there might be a performance penalty.

It's interesting to see that Mozilla attempted to prevent cross-site tracking when they decided to re-seed the PRNG for each JS context in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=475585

https://bugzilla.mozilla.org/show_bug.cgi?id=868860 is supposed to initialize the seed way better. Does that alleviate your concerns?

Trac:
Keywords: TorBrowserTeam201510 deleted, N/A added
Severity: N/A to Normal
Status: new to needs_information

Very related: https://lwn.net/Articles/666407/

Replying to yawning:

https://bugzilla.mozilla.org/show_bug.cgi?id=322529 has a long rambling discussion on this, and no patch.

FWIW ESR 45 will have this fixed.

Trac:
Reviewer: N/A to N/A

ff45-esr-will-have?

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