Re: [tor-talk] Cryptographic social networking project

[contact@xxxxxxxxxxxxx]

>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 - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk