Re: Random chaff [was: more work for Grobbages]
On Fri, Sep 18, 2009 at 10:19:17PM -0400, Ted Smith wrote: On Fri, 2009-09-18 at 04:25 -0400, grarpamp wrote: Nodes usually have a max bandwitch set. Nodes often comsume less than this. All node to node traffic is encrypted. Perhaps implement a random stream generator that only runs when it or its chosen path has free bandwidth, tags its traffic as chaff, pipes it through some number of nodes, or if it has idle neighbors, and ultimtely sink it somewhere. It would be even harder to follow an actual client dl/ul stream if things were maybe udp with the stream reassembly info inside each onion wrapped cell. Or something like that. No doubt this is old ideas. Indeed it is, and it's my understanding that this doesn't really work. More astute minds than I can explain in full, but you can render this sort of safeguard useless quite easily. The issue with padding isn't that it doesn't work at all, but that it doesn't work well enough to do any good. Last I checked, the state of the art in low-volume padding could slow down correlation attacks by 10-50%, depending on how you're counting. This sounds good until you think about how fast correlation attacks actually are. If a correlating attacker (one watching both ends of the communication) needs only a second of traffic to link sender and receiver, then forcing him to collect an extra half-second of traffic doesn't actually help the user very much, assuming that the user intends to use Tor for more than a second and a half. What would need to change for padding to become useful? If it turns out that correlation attacks are far more difficult than the research community thinks, or if somebody comes up with a padding approach that actually delays correlation enough[**], I think we should come back to the question. [*] You can do high-cost methods that defeat correlation[***] pretty easily: constant-rate traffic is one of them. There's a FAQ entry about why constant-rate traffic probably won't work in the wild: http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#YouShouldPad [**] What's enough? I'd say the lifetime of a circuit, but I might be wrong. [***] But you'd still need to worry about active attacks in this case. peace, -- Nick
Re: Random chaff [was: more work for Grobbages]
On Wed, Sep 23, 2009 at 3:38 AM, Nick Mathewson ni...@torproject.org wrote: On Fri, Sep 18, 2009 at 10:19:17PM -0400, Ted Smith wrote: On Fri, 2009-09-18 at 04:25 -0400, grarpamp wrote: Nodes usually have a max bandwitch set. Nodes often comsume less than this. All node to node traffic is encrypted. Perhaps implement a random stream generator that only runs when it or its chosen path has free bandwidth, tags its traffic as chaff, pipes it through some number of nodes, or if it has idle neighbors, and ultimtely sink it somewhere. It would be even harder to follow an actual client dl/ul stream if things were maybe udp with the stream reassembly info inside each onion wrapped cell. Or something like that. No doubt this is old ideas. Indeed it is, and it's my understanding that this doesn't really work. More astute minds than I can explain in full, but you can render this sort of safeguard useless quite easily. The issue with padding isn't that it doesn't work at all, but that it doesn't work well enough to do any good. Last I checked, the state of the art in low-volume padding could slow down correlation attacks by 10-50%, depending on how you're counting. This sounds good until you think about how fast correlation attacks actually are. If a correlating attacker (one watching both ends of the communication) needs only a second of traffic to link sender and receiver, then forcing him to collect an extra half-second of traffic doesn't actually help the user very much, assuming that the user intends to use Tor for more than a second and a half. What would need to change for padding to become useful? If it turns out that correlation attacks are far more difficult than the research community thinks, or if somebody comes up with a padding approach that actually delays correlation enough[**], I think we should come back to the question. [*] You can do high-cost methods that defeat correlation[***] pretty easily: constant-rate traffic is one of them. There's a FAQ entry about why constant-rate traffic probably won't work in the wild: http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#YouShouldPad [**] What's enough? I'd say the lifetime of a circuit, but I might be wrong. [***] But you'd still need to worry about active attacks in this case. peace, -- Nick So, if I understand this correctly, a correlation attack works (on a very basic level) by noticing that Alice sent a message to Bob (a known Tor node) at time X, and Dave (another known Tor node) sent a message to Wally (a web server) at time X+e, where e is about how long we would expect it to take for the onion to be routed. Is that more or less the idea? It seems like determining e (time to route the packet) with any degree of precision would be pretty difficult, so is this really a big problem? (or is that still being debated?) On the other hand, if an attacker could monitor a good number of nodes, wouldn't it be fairly easy to determine each three-node circuit segment (like Alice, to Bob, to Charlie) and trace the whole thing end-to-end? It seems like this could be defeated with a more intelligent type of chaff, where the receiving relay generates N random dummy onions (with an appreciable circuit length) for each onion it receives, and then sends all N+1 into the network in a random order. Then again, I may have completely missed the boat on this whole correlation attack thing. -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net
Re: Random chaff [was: more work for Grobbages]
On Wed, Sep 23, 2009 at 10:01:07AM -0400, Brian Mearns wrote: So, if I understand this correctly, a correlation attack works (on a very basic level) by noticing that Alice sent a message to Bob (a known Tor node) at time X, and Dave (another known Tor node) sent a message to Wally (a web server) at time X+e, where e is about how long we would expect it to take for the onion to be routed. Is that more or less the idea? Yes. But packet counting can also play a role. Cf, Passive Attack Analysis for Connection-Based Anonymity Systems at http://freehaven.net/anonbib/index.html#SS03 It seems like determining e (time to route the packet) with any degree of precision would be pretty difficult, so is this really a big problem? (or is that still being debated?) It's not. Cf. my Locating Hidden Servers http://freehaven.net/anonbib/index.html#hs-attack06 wherein we had zero false positives on any timing attacks conducted in finding hidden services, which generally was very quick. (That such attacks existed were known for years. That they were not just possible but so fast and effective using merely a single node in the network was the reason that guard nodes were introduced into the Tor network.) And building on that see, Low-Resource Routing Attacks Against Tor http://freehaven.net/anonbib/index.html#bauer:wpes2007 where timing attacks with epsilon false positives were based simply on circuit setup and were shown on general Tor circuits, not just for hidden services. On the other hand, if an attacker could monitor a good number of nodes, wouldn't it be fairly easy to determine each three-node circuit segment (like Alice, to Bob, to Charlie) and trace the whole thing end-to-end? It seems like this could be defeated with a more intelligent type of chaff, where the receiving relay generates N random dummy onions (with an appreciable circuit length) for each onion it receives, and then sends all N+1 into the network in a random order. There's been a lot of research on this. I think Nick pointed at some. Cf. the anonbib. Research against timing attacks continues. (I'm doing some myself.) But so far, any chaff strategy in the literature is both too expensive and not at all effective against active attacks on general low-latency systems for wide use, such as Tor. HTH, Paul
Unsubscribe
Unsubscribe -- The three fastest modes of communication ... telephone, telegraph and tell-a-woman. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Random chaff [was: more work for Grobbages]
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. On Wednesday 23 September 2009 10:59:03 am Paul Syverson wrote: On Wed, Sep 23, 2009 at 10:01:07AM -0400, Brian Mearns wrote: So, if I understand this correctly, a correlation attack works (on a very basic level) by noticing that Alice sent a message to Bob (a known Tor node) at time X, and Dave (another known Tor node) sent a message to Wally (a web server) at time X+e, where e is about how long we would expect it to take for the onion to be routed. Is that more or less the idea? Yes. But packet counting can also play a role. Cf, Passive Attack Analysis for Connection-Based Anonymity Systems at http://freehaven.net/anonbib/index.html#SS03 It seems like determining e (time to route the packet) with any degree of precision would be pretty difficult, so is this really a big problem? (or is that still being debated?) It's not. Cf. my Locating Hidden Servers http://freehaven.net/anonbib/index.html#hs-attack06 wherein we had zero false positives on any timing attacks conducted in finding hidden services, which generally was very quick. (That such attacks existed were known for years. That they were not just possible but so fast and effective using merely a single node in the network was the reason that guard nodes were introduced into the Tor network.) And building on that see, Low-Resource Routing Attacks Against Tor http://freehaven.net/anonbib/index.html#bauer:wpes2007 where timing attacks with epsilon false positives were based simply on circuit setup and were shown on general Tor circuits, not just for hidden services. On the other hand, if an attacker could monitor a good number of nodes, wouldn't it be fairly easy to determine each three-node circuit segment (like Alice, to Bob, to Charlie) and trace the whole thing end-to-end? It seems like this could be defeated with a more intelligent type of chaff, where the receiving relay generates N random dummy onions (with an appreciable circuit length) for each onion it receives, and then sends all N+1 into the network in a random order. There's been a lot of research on this. I think Nick pointed at some. Cf. the anonbib. Research against timing attacks continues. (I'm doing some myself.) But so far, any chaff strategy in the literature is both too expensive and not at all effective against active attacks on general low-latency systems for wide use, such as Tor. HTH, Paul -- “We can have a democratic society or we can have the concentration of great wealth in the hands of the few. We cannot have both.” — Louis Brandeis, Supreme Court Justice, 1916-1939
Re: Random chaff [was: more work for Grobbages]
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. The order uncertainty doesn't matter at this level of latency. 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. 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. Cf. the papers Nick and I mentioned before and others in the Freehaven anonbib. aloha, Paul
Re: Random chaff [was: more work for Grobbages]
*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
[OT]RE: Unsubscribe
You have to send to a different address. Instructions are in the headers. Subject: Unsubscribe From: tim...@gmail.com To: or-talk@freehaven.net Date: Wed, 23 Sep 2009 17:07:45 +0200 Unsubscribe -- The three fastest modes of communication ... telephone, telegraph and tell-a-woman. _ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/171222984/direct/01/
RE: Planning to build private network
Does anyone have any comments or sugestions for the person that posted the below, about one month ago ? I was very interested in this topic, but there were no follow-ups ... - I am currently planning to build a private TOR network for 50 users. The goal of the network is to provide anonymous browsing and access to hidden services for the group while trying to avoid the low speeds seen in the public network. The users will not be using the the network for file sharing or high bandwidth applications like streaming media. The group currently uses the public network, and 12 are hosting relays. The main complaint from the group is that the public network is too slow for comfortable use of some internet applications. (No big surprise) I have a few questions. 1) Will a private network address the speed concerns if built properly? I have read considerable amounts on the subject of TOR's speed, and understand that the number of relays is not the overriding concern. 2) If the answer to 1 is yes (i believe it is), what would be the optimum number of relays to ensure privacy and speed? Is there a formula that determines the number of relays need for X number of users, with a say a 3 hop path? What about hidden services? If there a rule of thumb for determining the number of exits to relays? 3) What would the minimum specs of a individual relay be? How much bandwidth per relay should we strive for? 4) Assuming we build it properly, and do not abuse it, what kind of speeds can we expect from the network?
Re: Planning to build private network
Similarly... I've fielded questions regarding using the public Tor for bulk data transfer, backups, distributed file stores and the like. But it always proves hard for me to resolve the impact in order to say go one way or the other. If they make a private Tor network, growth will be very slow because there are not enough nodes to ensure anonymity. If they use public Tor, it might get hammered. And it seems the long term survival of using either pub/priv for this depend on whether users both felt anon enough to give bandwidth and have enough bandwidth and the ethic to give it. If they do, the math works out ok. If not, the net tanks. And then there is the problem of authority servers. It would be nice if Tor had an automated election system where that function would roam about inside the Tor network itself as a self sustaining agent. Because right now, I think one could cut them off the net and take Tor with it.
Re: [OT]RE: Unsubscribe
downie - wrote: You have to send to a different address. Instructions [to unsubscribe] are in the headers. Having seen this situation on this list multiple times, it occurs to me that beyond To, From, and Date, many people have probably never seen the headers. Most non-techies probably don't even know it exists. I believe most GUI mail clients, by default, only show the abbreviated version I just mentioned. I know mine does. I don't know what the solution is, but I thought I would throw this out there for people's consideration. Jim
