Thank you for all the help, there is some big research on this problem you have showed me.
Let me clarify the attack I need to be defended: The user in California sends the E-Mail message from the web client provider, possibly 1Gmail to the 2Gmail address; all 3 Tor nodes in between were not compromised; Google's Internet Service Provider and Gmail were not tagging the traffic; only now as I stopped the writing and file sharing activity they are trying to retrospect and correlate my GISP account with the Gmail. NOW thanks to your replies I know that they could statistically link it very easily because I have used my Gmail only in new Tor Browser instance and I have used it alone from other sites as I wanted to be safe from IP/Time/Size correlation. How stupid I was? My actual questions are: 1. You have introduced me to the https://blog.torproject.org/blog/one-cell-enough and On June 15th, 2012 some other Anonymous said: "The Tor design doesn't try to protect against an attacker who can see or measure both traffic going into the Tor network and also traffic coming out of the Tor network. That's because if you can see both flows, some simple statistics let you decide whether they match up." Let the client download / upload random data from / to the relay with a speed at 10-50% (random speed that change frequently) at the download / upload speed. That is, if the download from the relay is with a current speed at 50 KB/sec, the client should download random nonsense data from the relay with a speed between 5 and 25 KB/sec. This result in a average speed at the random data at 30%, and that will not put a hard pressure on the network." Could this example exist as a "partial" solution in the form of the web application that I could run in the tab next to the Gmail and that would D/U random data making requests from and to the relay for some small or big files? Would in my threat model these still be partially correlated as requested Size (within the overall constant speed) would need to always be obfuscated by bigger Size responses than the real response Size? Other possible variant I see is that loading the full available bandwidth pipe of the Tor Nodes with (two) files would actually reduce the speed for the Gmail server watching and for the GISP it would be still bigger but would just be restricted to the Tor Nodes broadband ability and when the Gmail file is shared, the speed of D/U could jump up quick enough to not be correlate-able because GISP would constantly see the maximum bandwidth. Another variant is the continuous slowdown/speedup of all traffic by some mechanism in TBB or Nodes not by the D/U s o it would save the network bandwidth but this is the most insane to propose. What variant is real to deal with or all are garbage? 2. If the web application from the second question could start to partially help the Size obfuscation problem except the GISP to Entry Node requests that are needed to be somehow shown to the GISP by the TBB to Entry Node connection (is it true?), could the requests of TBB potentially be served encrypted and delayed enough so that even so the Gmail server would see the “real” requests timing, the timing would be obfuscated for the GISP to Entry Node connection with a very little delay that would be synchronized with other very little delays that are continuously being sent to and from the Entry Node? These sub-second delays that would just not be the big problem to the Gmail user but all the GISP to Entry Node activity would be synchronized and optimized according to usage and behavior templates like "Reading", "Writing", "File sharing".. for the GISP it would only be these or more common traffic like “Default”? That is if the bandwidth traffic is obfuscated and what is left to obfuscate is the time of request, the time of ordered changes in this bandwidth traffic. What could I know there are many new types of Web connections and I don't know a simple http. There are so many papers from people far better educated than me that I don't have a time to understand. I think that serving constantly obfuscated speed when needed and requests when they are correlated and indistinguishable of artificial going on pair should defend the described attack and I don't know why it is not possible for implementation. Don't laugh and don't spend your time too much on my propositions, please. It is all for the more arbitrary choices, not for a generalization of the TBB standard. Peace, and God damn the age of stylometry. _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
