[tor-dev] Effect of padding on end to end correlation false positive rate

[s7r <s7r@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

I have an idea which I want to put into a proposal, but need a
clarification first so I won't be working on something which doesn't
make a big difference.

I am describing something like a Sybil attack where the adversary runs
relays, gets lucky and is selected in a certain position of a certain
rendezvous circuit and can do an end to end correlation of the traffic
(both ends). This is different from one end correlation or website
fingerprinting attack.

For this scenario:
HS -> Guard -> Middle1 -> Middle2 -> RDV -> MiddleC -> GuardC -> Client

If the client is the attacker, and Middle1 is an evil relay colluding
with him, and it was selected 2nd hop in a rendezvous circuit that
connects the HS with the attacker (rendezvous is not colluding), he
can learn the guard of the hidden service. The client (attacker) can
send traffic over that circuit until he gathers enough data to make a
fair assumption about where the traffic is coming from (identify the
guard of that HS). I am not sure if there will even be a nonzero false
positive rate in this context. Confirmation needed for these
assumptions, this is what I think after reading: [0],[1].


Does this change with padding? If yes, how?

For the same scenario described above, if padding is used, will the
attacker have to own the entire path to the guard (Middle1 and Middle2
in the same circuit, since the rest of the path is under his control
to select anyway), in order to make a reasonable guess on which might
be the guard he is interested in?

Or can he make the difference between the real traffic and the padding
/ dummy traffic and have the same results as with no padding?


[0]: https://blog.torproject.org/blog/one-cell-enough
[1]: https://blog.torproject.org/blog/traffic-correlation-using-netflows


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWIU5yAAoJEIN/pSyBJlsRlj4H+wcAc958SazmoXgYTtJisK5R
dgcWZILgnYTYg17ub8Y3Hsgh0YjJyEgwgXV/r6ftNNir8kMSn3t+KMFAt9OpVhOJ
4W0f3E/X18viJNn3Pcb3FDc41sXxpwMVdUd337wGzqaNb8wsCARspmkDv9gdsLje
GTTrz2MUa6lWyZHEuJMp02W2pkPVr48UnOsd0S0lyiDM3uxAAQyEtS9XwQyd+hBE
KgLG7DHgwOnNzpBeQYJ5KlTzWi6j/NGxXcnHWcuWkq32ZG/gQsw6I43BNV9DMs6r
3UJbrdHsYJKDq8I16Ir0fblaOjsxmU7cEZZioOVngmw8wG6KevGI7fYKsEcqAhk=
=CJly
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev