People usually recommend either using a VPN or hosting an entry or exit node in a remote server. But what about proxies and bridges, for example? And are there any other way to avoid correlation attacks?

  • 1
    You really can't, adding a VPN only means both VPN provider and your ISP and the guard are in a position to perform the attacks. They're a problem that's general to (most? all?) existing low-latency anonymity networks.
    – cacahuatl
    Commented Aug 7, 2017 at 16:52
  • you can find some more information on traffic correlation attacks here. blog.torproject.org/blog/traffic-correlation-using-netflows
    – Tommy
    Commented Aug 11, 2017 at 22:05
  • Please don't just link to some webpages, but describe the solution and additionally link to pages.
    – Jens Kubieziel
    Commented Aug 13, 2017 at 19:44

2 Answers 2


What prevents you having a second circuit that shares entry node but not exit and adds noise by inflating entry node hroughput. Can the entry node see individual packets? I assume not ... just aggregate bandwidth and timing. Noise generation would destroy size correlation and blur timing.

Now all thats left are longer term timing attacks at the session timescale. Being a helper node may assist with that ... with your noise generator filling in any long silences you can effectively concatenate discrete sessions.

Not strictly bandwidth friendly, but if the alternative is torture... y'know : )

What we could use is the ability to ask middle nodes to randomly hold or buffer both requests and responses. Perhaps even adding overhead with varilength 'null packets' ... and absorbing nulls sent by the client.

Send in 10 13 11 ... and 2 mins later a request of size 34 is released. A response comes back as size 2000 and is forwarded 201 459 134 etc... mixed with a few nulls and the correlation blur is significant.

I wonder if an HS could be useful for timing, padding and deferral. Essentially making a tor-to-tor supercircuit with user selectable jitter and latency... for those who would trade immediacy for correlation protection.

Just some thoughts ... don't shoot!

  • "Can the entry node see individual packets" It can see individual cells, which is sufficient. "Noise generation would destroy size correlation and blur timing" Not for the entry guard, no. And it wouldn't blur timing for others either. Adding "noise" is oft suggested but not as simple as it may first sound and it's expensive. This is covered in the Tor Project FAQ: torproject.org/docs/faq.html.en#SendPadding
    – cacahuatl
    Commented Dec 8, 2017 at 12:35

As boring as it may sound, I think the most you can do is to use as much default torrc settings as possible. Don't manually pick relays for example. Oh, and use TorBrowser instead of setting up another browser to use Tor. If you can, use Tails.

  • Even if a relay is a relay I set up myself? For example, the entry or exit relay? Commented Jan 24, 2018 at 19:36
  • Well I think so. tor's default path selection properties are researched to be the most safe for everybody. If you interfere and restrict tor's behaviour, you may open random attack vectors.
    – merge
    Commented Jan 25, 2018 at 10:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .