*sigh* See below :) On Sep 23, 2009, at 8:29 AM, Paul Syverson wrote:
On Wed, Sep 23, 2009 at 11:11:29AM -0400, Praedor Atrebates wrote:It would appear that the tor network should include some timing randomization and reordering of packets to thwart such analysis. Not so much to really slow things down but enough to throw up uncertainty in the packet analyses.You're trying to turn it into a mix network.
That's something that exists in "that box" over there, not "Tor's box" ;)
The order uncertainty doesn't matter at this level of latency.
AKA, as little of latency as possible... which is still quite a bit actually, thank you bittorrent :(
The Bauer et al. research I mentioned showed how to do timing attacks based just on setting up the circuit. You don't even need to send any data.
*shrugs*If all clients in the network created Tor circuits of the same length, all at the same time, wouldn't that mangle that analysis of who's telescoping circuit-extension request is who's? I know that's not what cover traffic does... but if Tor has some sort of "heart beat" that would make it more difficult to distinguish between which circuit- extension request is who's... that's only feasible because all clients have a stake in circuits, not the same for external-to-to requests, like webpages etc etc...
Whatever solution (if one even exists) is out there, most of the straightforward ideas and many of the not so straightforward ideas have already been extensively researched.
But not necessarily tested in the wild... Even the Bauer et al. demonstrates those ideas in a fake Tor network, yes, on recommendation from Tor not to do the experiment in Tor, but still. And on PL, the VM environment is particularly prone to latency, so of course timing analysis attacks will stick out like a sore thumb...
so there might actually be something to deploying that exp on the real network...
Cf.
what does that mean? :)
the papers Nick and I mentioned before and others in the Freehaven anonbib. aloha, Paul