Enhanced Security Suggestion

Could a random traffic delay be incorporated into the routing algorithm, in order to thwart traffic timing on the nodes. Random packing of data might also be necessary to avoid the detection of packet sizes through the nodes?

Trac:
Username: forever

changed milestone to %Tor: very long term

added component::core tor/tor milestone::Tor: very long term priority::low reporter::forever resolution::not a bug severity::major status::closed tor-relay type::enhancement labels

This is an open research question, and out-of-scope for the Tor bugtracker. If you're interested in chasing it down, you could start with some of the traffic analysis and anonymity papers at http://freehaven.net/anonbib/ . See also the padding-related FAQ entry at https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Youshouldsendpaddingsoitsmoresecure. : the same logic applies to random delays.

The short version is for every studied means of adding random delays or traffic padding to low-latency anonymity network, either it requires so much delay/padding that it isn't deployable for low-latency traffic on a volunteer-operated network, or it doesn't actually delay attackers long enough to be useful, or both. Whether this is true of all traffic padding/delay schemes or not is an open research question.

Also, the question about packet sizes suggests that you could take some time to read the spec or the design paper; both explain that Tor doesn't send variable-sized packets of user data.

Closing for now: if anybody solves the research questions here and find a means of padding/delay that does resist attackers well on a low-latency network, we should reconsider.

Trac:
Resolution: N/A to not a bug
Status: new to closed

Trac:
Keywords: N/A deleted, tor-relay added

Trac:
Component: Tor Relay to Tor

In the last 7 years there has been much research on the subject. It is not a bug, but neither are any feature requests. It is a hope that the specifications will be improved, rather than the implementation. 7 years ago only rich countries could passively break Tor using timing and size information, but now any script kiddie on your public hotspot, ISP, or carrier can do it. The most severe consequece of this is that brutal dictatorships such as Egypt and North Korea have started using the attacks to stalk journalists/whistleblowers and torture or murder them. Although the demands of the Internet have increased in the last 7 years, the infrastructure to support it has increased as well, as have the techniques for mitigating the negative effects of bad latency, and it is also easier than ever for data to be compressed more than ever before. Due to all of these advances, padding of latency and packet size should no longer require making the user experience awful. Obviously there will be arguments over how much padding there should be, and diminishing returns of greater padding. However, specifying that Tor shall have padding built in, and implementing some very small overhead by default (say, 0 to 1% extra latency and 0 to 1% extra packet size) wouldn't hurt anything, it would break all the existing cyberweapons used to attack Tor users, and hopefully by the time all of those weapons are upgraded there will be a consensus on how much padding there should be. A lot of third world countries might never get such an upgrade, and first world ones are less likely to murder journalists.

I've never written in a low level programming language so it's beyond me to even tell which of these studies will help to write the patch, but here are some studies; https://duckduckgo.com/html/?q=traffic%20padding%20anonymity%20research https://duckduckgo.com/html?q=latency%20padding%20anonymity%20research https://duckduckgo.com/html?q=packet%20padding%20anonymity%20research https://duckduckgo.com/html?q=timing%20correlation%20anonymity%20research

Trac:
Sponsor: N/A to N/A
Milestone: N/A to Tor: very long term
Status: closed to reopened
Actualpoints: N/A to N/A
Points: N/A to N/A
Reviewer: N/A to N/A
Priority: Medium to Low
Severity: N/A to Major
Resolution: not a bug to N/A

Let's leave this one closed; it's 7 years old, and there are other tickets for studying padding and adding it; for example, see the work stemming from #16861 (moved).

Trac:
Resolution: N/A to not a bug
Status: reopened to closed

closed

moved to tpo/core/tor#1880 (closed)