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?
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!
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.