[tor-dev] high latency hidden services
michael at briarproject.org
Thu Dec 11 13:26:23 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
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
* 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
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:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the tor-dev