Well Google is not the service to use if privacy is a concern, either way if your really concerned about obfuscating. Entrance node should be through a VPN, then route and relay.
On Sat, Mar 23, 2013 at 4:51 PM, <avarageanonym...@hushmail.com> wrote: > If my latest two questions were not meaningful I am asking as meaningful > to the current TBB as I can: > > In a default TBB would the GISP(Google-owned Internet Service Provider) > see the traffic coming to Entry Node as a mix of separate connections that > are approximately the same size and time comparing to the direct GISP to > Gmail connections? Maybe my example is bad as Google use https and the size > would be somehow different but I hope you will get my point at large. To > address my problem for the obfuscated mix of connections I should use the > obfsproxy connection that is by design hiding all the real connections to > the one(1) obfuscated so the GISP looking at the TBB to GISP connection > would just see one constant connection (with all the real connections > obfuscated and mixed into this one) of variable upload and download speeds > (because the web application would help to make it variable by speed but > constantly open connection)? > > Bless the Entry Guard. > > > On 03/19/2013 at 10:45 PM, avarageanonym...@hushmail.com wrote: > > > >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 > >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 so 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 > tor-talk@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk