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

[grarpamp]

On Fri, Oct 16, 2015 at 3:22 PM, s7r  wrote:
> 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

> Does this change with padding? If yes, how?
> [1]: https://blog.torproject.org/blog/traffic-correlation-using-netflows

My thought was solely restricted to analysis of network
traffic by *passive* adversary... not involving any collusion
by actives over circuits they can see inside or pump within
any given onion layer, though clocked and checked network
fill by all proper nodes would inhibit pumping by actives.
I talked on list with someone at briarproject and wherever
else on idea of filling the network with traffic vs the passives.
Apologize for not making time to review Mike's proposal
or develop further talk yet. Someone will review / integrate
fill padding of network with regard anonbib, Mike's, etc I'm sure,
as it is clearly (to me at least) a weakness of non-filled
non-store-and-forward networks vs the passives which we
all know and love.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[s7r]

-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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev