>So let's assume less than 1% of Facebook users use this.. let's take >a million for example. Hundreds of thousands of Tor users would then >be keeping hundreds of circuits open while they are interacting with >the Bulk data servers. What do Tor backend experts think of this >scenario?
I think you are criticizing using Tor because it can't handle load in mass scales. Using any other approach for anonymization have same problem, note that only multi-hop proxies like onion routing can foil traffic analysis, simply distributing data across p2p nodes by assuming that there is no a central service provider to look at data in its control panel won't protect your network's metadata. The only solution is encouraging more volunteers to run Tor relays for increasing its capacity rather than saying that if millions of users try use Tor they can't. By the way keeping circuits open theoretically won't computationally cost much CPU power for relays, only opening circuits require asymmetrical cryptography which is the expensive part and as i said when Alice open a circuit to Bob she won't drop it as long as middle relays are available. I'm not worry about Tor. It would be awesome if as you said millions of more users try use it because when they learn about Tor, they also learn how to run a relay. Tens of millions around the world are paying to install Anti-virus softwares on their desktop computers which massively harm their security and freedom, running a free Tor relay is much easier than installing an Anti-virus environment, except that it greatly increase their security and freedom. With more relays beside more scalability, also chance of controlling both entry and exit nodes become harder for powerful adversaries to deanonymize origin of Tor circuits. I think with more relays Tor team itself finds opportunities to adopt even more security mechanisms that make it harder for attackers to correlate patterns which increase the load on Tor network, such as adding random size padding to traffic at relays. It's a matter of enlightening and soft power. >Why would you add attackers to your social network? >You think you gain social score by that? >Of course such a social network must disincentivate adding strangers. >No, we would call it "round robin" if it wasn't doing multicast. >I don't see this lack of trust scenario you are painting. >We are doing a social application, it is natural for a social >application to trust the other members of the same multicast group >to cooperate on achieving the common goal. I'm not sure what is "round robin". You can't rely on friends as a remailer to deliver things, how is communication between friend1 with friend2 secured to ask friend2 deliver something to friend3? If you directly send it then ISP/government/any-other-attack-in-between can simply discover a relation for friend1-*-friend2, if you use a multi-hop proxy to anonymize their connection then you have to trust Tor for protecting metadata as we do. Also friends might be unavailable (which make it difficult decide send data to whom as you don't know which friend is going to remain unavailable for how long) and we must instantly deliver everything to all recipients whenever user share something. Furthermore your plan for handing over entire data so many times among friends seems much more complicated+expensive than simply directly sending a few byte long packet to both Bob and Bill synchronously (hidden service) or asynchronously (public pool) in our case... If you are thinking about creating something like a low latency TCP stream using members of your network to deliver packets within reasonable time then It's not a good idea to design an anonymizer on your own that it's vulnerabilities are not clear to the community and nobody care about it. Tor gets so many research papers, enormous code audit, warm attention from hackers and intelligence agencies every year but still isn't fully deployed. We just created everything under Tor. >You didn't comment this part. So a million people also keep >refreshing circuits to a cloud of PseudonymousServers for >each line of chat going on on any profile. Yes? I described circumstances to generate a new Tor circuit for a new identity. You can load many "Blocks" using same Tor circuit but for saving a new "Block", circuit need to change. For instance when Alice post a new comment or message she change her Tor circuit before uploading the "Block" but all her friends to download that "Block" won't change their Tor circuit to "PseudonymousServer". Actually it's not essential to change the circuit before saving a new "Block", it doesn't compromise metadata to upload a new "Block" without establishing a new circuit. "PseudonymousServer" might learn these new "Blocks" are created by same persons who created those other "Blocks" but it doesn't tell anything about who created them or who is going to retrieve them. Even correlating new "Blocks" to each other is very hard for "PseudonymousServer" because it only sees "Blocks" coming from Tor exit nodes and many different users use exact same exit node to save new "Blocks" on "PseudonymousServer" which make it impractical to correlate "Blocks" that are coming from same exit node... So, No users won't change their Tor circuit for new comments or messages. >And then there's traffic shaping. With more relays and adding more security layers (e.g padding etc) in the future, if Tor team overcome software bugs then there is no need to worry about deanonymization, at least for majority of users. One of the main protections against global adversaries with controlling both ends of circuits, is exerting very high delay for TCP packets (yet unknown how long) that makes loading web pages very slow which disturbs users who are waiting to view entered URLs (which even make difficulties for relays themselves as keeping data for applying delay requires large storage buffers...), but in our case as users don't know when a new post/comment might appear in their timelines, it won't disturb them if app display posts with some delay. So if later on Tor team provide a different relay software for volunteers to launch a new parallel onion routing network beside their current low latency network, for applications like us that are able to endure inconvenience of delays then we surly will look into adopting it for more protection against global adversaries. Now Tor is not our concern, we are looking for possible mistakes in our own software, such as crypto parts, functional bugs, key management et cetera. If you found any problems on those sections please let us know. -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
