-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Tor-Dev,
I'm curious what the timing is of Tor's opening of preemptive circuits.
Specifically, consider the following attack:
1. A new stream is assigned to a clean circuit.
2. Because of the above, that clean circuit is now a dirty circuit.
3. Because of the above, the number of clean circuits is now decreased
by 1.
4. Because of the above, the number of clean circuits is now lower than
the number that Tor wants to have open.
5. Because of the above, Tor opens a new preemptive circuit.
6. An attacker who can observe the circuit in (1) and the circuit in (5)
can deduce by temporal proximity that those 2 circuits belong to the
same client.
This attack seemed obvious enough to me that I assumed that Tor must
have some kind of countermeasure to it, e.g. random delays in opening
preemptive circuits. However, the tor-path specification doesn't
mention any such countermeasure, and based on a brief search through the
Tor source code, all I can find is that Tor opens preemptive circuits
using a function that always gets called once per second (with no
mention of any delay beyond that one-second interval, random or
otherwise).
So, does Tor make any effort to mitigate the above attack? If so, what
mitigations are present, and where would I find them (in both the spec
and the source code)? If not, is there any documented reason (e.g. "the
attack is too hard to pull off" or "we want to mitigate it but haven't
gotten to it yet") for the lack of mitigation?
Cheers,
- --
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmobile(a)airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jeremy(a)veclabs.net is having technical issues at the
moment.
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEVB3fdzAraEcoBtkSs/LRZXhtZXAFAl2CoycACgkQs/LRZXht
ZXDyjhAAk3F6fJUvNl4FHws6IIBHWXby/zC7MLzr9zR3sIC3RY4f/I7XBDTKKfMg
iOehJlBEksm5sRz6nlybUBivsJ0WRL8VCT3rEK3+LQM7JrYNvGajolEw2apBUeB3
+Vg+Quo5JzTZrjCtXljxdps/hhC1YwEyN6pxxn2137q4XAsRPQgSCcWpsBuDTffb
LFRwyGrNxk6chbpQc0GIWQRoeElxFwaLbUrZdGtaaEjBXY2oWoan1TUB34MAVNzF
1o6DlaO2JQ7weHVHoXlTlXS7gt84/WyY0xaHUY9ONHwrhgDPGv3N5+Fa2Em+PvGx
ik+4iSCzPf6aKY0iUv1AsWKiaq8rRsMToyNzNZ048uYHk2IK2Zrbqh4Nm44RTzKD
84tJU71calRdNhbwuvmgsYKh26Ad9ALf9BzDeiweA3c5ZP0JP0OlLcAN9c056WT3
FQbChA1edZkWkPvBjGtl4l7ROIx6wkNpWgaQsYUCMveszB2Rm38BQw5sYLh8i6ha
AlT3UVs/GJscSSsfmHGrTisao444Etp4J/+SFe1aNJwfOogbEfgJ1jRf8V5dlYEb
rcicgkwmnBf01vnVaUO9C6/lToUa9i7r3BD3s6OQW24qz2ixieS3K6NxxxqMrVQ1
vFArleJIYA/FsDM2NPbeaUQA9z5GJj5X3FcPUPLLF+y5G/0HE14=
=aBRL
-----END PGP SIGNATURE-----