Re: [tor-dev] high latency hidden services

[Michael Rogers <michael@xxxxxxxxxxxxxxxx>]

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

On 10/12/14 00:14, grarpamp wrote:
> Guilty of tldr here, yet similarly, with the easily trackable 
> characteristics firstly above, I'm not seeing a benefit to
> anything other than filling all links with chaff which then hides
> all those parameters but one...

I'm not opposed to this approach, but "filling all links" isn't as
simple as it sounds:

* Which links should carry chaff? We can't send chaff between every
pair of relays, especially as the network grows.

* How much chaff should we send on each link? At present relays don't
divide their bandwidth between links ahead of time - they allocate
bandwidth where it's needed. The bandwidth allocated to each link
could be a smoothed function of the load - but then we need to make
sure that instantaneous changes in the function's output don't leak
any information about instantaneous changes in its input. That isn't
trivial.

* Is it acceptable to add any delay at all to low-latency traffic? My
assumption is no - people already complain about Tor being slow for
interactive protocols. So we'd still need to mark certain circuits as
high-latency, and only those circuits would benefit from chaff.

Once you fill in those details, the chaffing approach looks pretty
similar to the approach I suggested: the relay treats low-latency
circuits in the same way as now, allocates some bandwidth to
high-latency traffic, and uses that bandwidth for data or padding
depending on whether it has any data to send.

> I can't see any other way to have both low latency and hide the 
> talkers other than filling bandwidth committed links with talkers. 
> And when you want to talk, just fill in your voice in place of the 
> fake ones you'd otherwise send. That seems good against the GPA 
> above.

The alternative to filling the link with talkers is mixing the talkers
- - i.e. preventing the adversary from matching the circuits entering a
relay with the circuits leaving it. But as I said above, when you get
down to the details these approaches start to look similar - perhaps
they're really just different ways of describing the same thing.

Some papers on this topic that I haven't read for a while:

http://acsp.ece.cornell.edu/papers/VenkTong_Anonymous_08SSP.pdf
http://www.csl.mtu.edu/cs6461/www/Reading/08/Wang-ccs08.pdf
https://www.cosic.esat.kuleuven.be/publications/article-1230.pdf

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUiZt+AAoJEBEET9GfxSfMYsQH/iMCSvmQYxjGFZC5lzvpT06Z
Ggjk+mflVkEDCKPt8e8ucQ7dp1URi9BS0wgxvo1PtSvEaO1C6m9NgyWHsNTXAMEn
otpjn9szudJP1YV2vzWUrr32gWHK8ZLiji9JBlKW2fZXwkliSM9nltqgvRUeIXvD
9r/T5S5VDNFoow++05XASHCUjoQmj2baEO3H8xag+MEcy4vEMPby9Yf5pPVbEoEv
uDwkRvRqqttUl7KC7A04M60214/LE/UCwKPlMzZRLjEo2dKPcnXxY5GWLz19OZ31
tawt8y8I/QRgn6l6R/W059eJkJKze1IqhEC8z5+IQD8SaTmY9Lxs10CqB9JGhMs=
=BW/U
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev