Opened 9 years ago

Closed 2 years ago

#1880 closed enhancement (not a bug)

Enhanced Security Suggestion

Reported by: forever Owned by:
Priority: Low Milestone: Tor: very long term
Component: Core Tor/Tor Version:
Severity: Major Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


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?

Child Tickets

Change History (5)

comment:1 Changed 9 years ago by nickm

Resolution: not a bug
Status: newclosed

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 . See also the padding-related FAQ entry at : 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.

comment:2 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:3 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:4 Changed 2 years ago by cypherpunks

Milestone: Tor: very long term
Priority: MediumLow
Resolution: not a bug
Severity: Major
Status: closedreopened

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;

comment:5 Changed 2 years ago by nickm

Resolution: not a bug
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.