[tor-dev] high latency hidden services

Michael Rogers michael at briarproject.org
Thu Dec 11 13:26:23 UTC 2014

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

* 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:


Version: GnuPG v1.4.12 (GNU/Linux)


More information about the tor-dev mailing list