3 ms·

Tor already "pads" to cell size. There is ongoing work towards better padding. Look at WTF-PAD for more. It is surprisingly difficult to improve padding effecti

by gye 8y ago

Tor already "pads" to cell size. There is ongoing work towards better padding. Look at WTF-PAD for more. It is surprisingly difficult to improve padding effectively, and you just can't add delays to TCP streams. Tor is not "refusing to add" either of those things. A more recent and thorough real world analysis of the traffic correlation problem is https://www.freehaven.net/anonbib/#ccs2013-usersrouted https://www.freehaven.net/anonbib/#ccs2013-usersrouted . In general, that site has a lot of great papers on these topics.

nickysielicki 8y ago
> you just can't add delays to TCP streams. Why not? I'm talking about shuffling queues such that it cannot be determined that a given node is relaying traffic in the order that it receives it. This is how most packet shaping works, no? At a minimum, I would expect Tor to be more secure by having nodes: * Not process traffic in the order in which its received, obfuscating the cause-and-effect of a packet being received and a packet going out * Pad traffic substantially with garbage such that the outgoing size cannot be associated with whatever came in, potentially splitting packets in half so that they can appear smaller than they actually are, forking around many different nodes. * Sending lots of random garbage traffic between relays such that input and output is meaningless overall, perhaps relaying packets to several nodes needlessly, when only a single node is instructed to actually do something with it. To my knowledge, Tor doesn't do any of this and has explicitly ruled out the possibility because they're more concerned with usability than security. And maybe that's the right call to make in the end, I don't know enough to say. I'm just saying that it's possible to imagine a system like Tor that is more secure than Tor, and that's something worth talking about. I'll check that link out, thanks for posting it.
- BearsAreCool 8y ago
  TOR aims to also be fairly low latency/bandwidth and many of those suggestions would probably destroy that.
- gye-44 8y ago
  Your ideas are correct but not easy to do. Browse the Anonbib and you will see lots of designs being discussed over what is now more than 30 years of research. Yes, Tor favors usability, also since previous attempts at safer systems were never adopted by enough users (Mixmaster, Mixminion). Already lots of people pick less safe options because "Tor is too slow". If you make it slower, you lose users, and everyone loses anonymity. That's only part of the answer and not the only argument against some of the changes proposed. I highly recommend the original design paper. [1] It touches on the very valid suggestions you make, and the tradeoffs. Sadly, not much has changed since. If you have a valid proposal, and you double-checked briefly what is covered on Anonbib as previous considerations, post to the tor-dev list and it will be looked at by Tor developers. At least that is my experience from following that list. https://svn.torproject.org/svn/projects/design-paper/tor-design.html https://svn.torproject.org/svn/projects/design-paper/tor-des...

by gye 8y ago

nickysielicki 8y ago

> you just can't add delays to TCP streams. Why not? I'm talking about shuffling queues such that it cannot be determined that a given node is relaying traffic in the order that it receives it. This is how most packet shaping works, no? At a minimum, I would expect Tor to be more secure by having nodes: * Not process traffic in the order in which its received, obfuscating the cause-and-effect of a packet being received and a packet going out * Pad traffic substantially with garbage such that the outgoing size cannot be associated with whatever came in, potentially splitting packets in half so that they can appear smaller than they actually are, forking around many different nodes. * Sending lots of random garbage traffic between relays such that input and output is meaningless overall, perhaps relaying packets to several nodes needlessly, when only a single node is instructed to actually do something with it. To my knowledge, Tor doesn't do any of this and has explicitly ruled out the possibility because they're more concerned with usability than security. And maybe that's the right call to make in the end, I don't know enough to say. I'm just saying that it's possible to imagine a system like Tor that is more secure than Tor, and that's something worth talking about. I'll check that link out, thanks for posting it.

BearsAreCool 8y ago
TOR aims to also be fairly low latency/bandwidth and many of those suggestions would probably destroy that.
gye-44 8y ago
Your ideas are correct but not easy to do. Browse the Anonbib and you will see lots of designs being discussed over what is now more than 30 years of research. Yes, Tor favors usability, also since previous attempts at safer systems were never adopted by enough users (Mixmaster, Mixminion). Already lots of people pick less safe options because "Tor is too slow". If you make it slower, you lose users, and everyone loses anonymity. That's only part of the answer and not the only argument against some of the changes proposed. I highly recommend the original design paper. [1] It touches on the very valid suggestions you make, and the tradeoffs. Sadly, not much has changed since. If you have a valid proposal, and you double-checked briefly what is covered on Anonbib as previous considerations, post to the tor-dev list and it will be looked at by Tor developers. At least that is my experience from following that list. https://svn.torproject.org/svn/projects/design-paper/tor-design.html https://svn.torproject.org/svn/projects/design-paper/tor-des...