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