On Thu, Jun 18, 2015 at 12:51 AM, Roger Dingledine
but it sure looks like another case of somebody not understanding the research field, and thinking that solving the traffic confirmation attack is easy, without actually thinking through the engineering side, the scaling side, or the statistics side.
There's certainly no easy solution to all problems. Though there could be value in those that put more odds in your favor, even though they do not yield 100% solution or protection. If you rarely tx but then emit something [unique or timely] that pops out at some [rare] destination, you're done for. I think we've seen posts from some people who slow crawl the web 24x7 when their client is running just to add cover at their end for their interspersed real web activity. By the way, does metrics report the saturation level of the net as a whole in terms of bandwidth and processing load for exit and non exit relays as both one [and two] summed aggregate group[s]?
But even full scale padding, ignoring the practical side of how to get a Tor network that can afford to waste so much bandwidth
Waste is an incorrect, negative term for designed in padding (fixed set of lengths) or fill (empty links) or chaff (ratio) or whatever this is. A design where fill traffic gets out of the way when real data is being sent might have periods of congestion or underutilization of the link depending on the distance in hops the fill is managed over, and the speed of the sensing and feedback controls. Seems that might need to be as fast as you could initiate a first packet across, unless you inhibit that packet until ready. Yes, an individual relay or end node may be subject to various billing policies (transfer vs bitrate), but see thread in reply to Titov here... https://lists.torproject.org/pipermail/tor-talk/2015-May/037987.html https://lists.torproject.org/pipermail/tor-talk/2015-June/038027.html
doesn't provide protection in the face of active attacks where you induce a gap on one side and then observe the gap on the other side. And it might even be the case that these gaps happen naturally by themselves, due to network congestion and so on, so maybe passive observers will be winners even against a design that does full padding.
I've said that fill seems useful against passives, not actives. However a design may actually be possible such that any disturbance or deficiency in fill might be possible to make up from other sources. In other words, if I knock you off the net, the remaining path your data would have taken to your endpoint will still be filled so as not to expose the far end as being tied to you (if the fill management scope of the network is finer grained than just the end nodes negotiating end-to-end with each other (ie: I think the entire net will need to negotiate their own mesh of fill peers as an underlying management layer, with possible cues from above)). You get knocked off, your former peers sense this and recalc their fill sources and sinks.
Also, to make it really work in practice, all users are going to need to pad not just while fetching their web page or iso or whatever, but sufficiently before and after that too, else an attacker can match up start times and end times: http://freehaven.net/anonbib/#murdoch-pet2007
Well duh, that's necessary :)
tl;dr the whole premise of this person's blog post is flawed, since their design likely does not work as they think it does.
While someone's design may be insufficient to solve some problem, it does add value in the form of talk of possible solutions and trialing them. Thereby others can try different / related avenues to a solution.
For background see e.g. http://freehaven.net/anonbib/#danezis:pet2004
This is a great area for further research: http://freehaven.net/anonbib/#ShWa-Timing06 http://freehaven.net/anonbib/#active-pet2010
I don't mean that Tor specifically needs to investigate or implement fill, but that since the research area is probably not complete, and that no operational net is trying it, it's worth continued work. If anyone knows a good list that does or would serve as home for such work, please say so as I'm unaware of any. [Bcc'd to matryoshka as FYI]