Re: [tor-talk] Cryptographic social networking project

[contact@xxxxxxxxxxxxx]

>Most transactions on a social network are one-to-many
>distributed messages.. your model provides postings
>and comments to postings, both requiring "hundreds" of
>circuits to hidden services being established or
>maintained each time something happens on one person's 
>timeline. In your example, Alice has 167 friends,
>therefore if a posting of hers triggers a conversation,
>her node would have to relay each piece of conversation
>to 167 other hidden services without a distribution
>strategy.

User only establish hundreds of Tor hidden services once, when launch
the app, which cost high computational power for awhile, but when all
hidden services are connected then it doesn't cost much CPU power to
keep connections alive and there is no reason to change hidden service's
circuit in order to send new "Notifications" to Bob, Alice can send
hundreds of "Notifications" to him through same hidden service circuit.
The real problem with current hidden service setup is that it doesn't
support sending keep-alive packets with high delays to keep circuits
open which cause battery problems on mobile devices because constantly
sending keep-alive packets doesn't let the device go to sleep mode but
Tor can solve this problem and many others in their next generations. 

>We are specifically developing
>a multicast distribution layer into GNUnet to address
>these types of use. See http://secushare.org/scalability [1]
>and http://secushare.org/pubsub [2] for further details.

If by "Multicast" you mean send the packet to one node to send it to all
others, then you need fully trust that node for anonymization which
motivates attackers to run malicious nodes because even with small
fraction of nodes compared to whole network, they can deanonymize users.
If your "Multicast" protocol sends packets to all receivers separately,
then it doesn't make any difference with sending a TCP packet to all Tor
hidden services... 

>But that's not all yet, according to your document
>each posting or comment isn't actually delivered directly 
>but rather stored in form of what you call a "Block" on a
>"PseudonymousServer." All of the 167 recipients have thus
>to maintain a circuit to one or more PseudonymousServers
>in order to retrieve the ongoing comments of the discussion.

>This also opens up doubts concerning anonymity. If a
>global passive observer can correlate EntryNode activity
>with the traffic going in and out of PseudonymousServer,
>wouldn't it be likely that very similar bursts of Block
>retrievals would allow to reconstruct the social graph
>of Alice?

As mentioned in document, we assume anonymity works. If attacker can
break Tor, i guess no other protocol can resist them to anonymize
metadata. All metadata protection protocols have some degree of trust on
distributed nodes that handle anonymization, high latency onion routing
networks provide more protection against correlating timing attacks but
it doesn't worth the trade-offs because a global adversary that watch
entire planet still can compute correlations on enter-exit points of
communications. 

We learned even NSA
(http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-presentation-document)
can't break Tor in mass scales and that give us enough confidence for
the rest of attackers, too. 

>Even more, if the attacker p0wned this specific
>PseudonymousServer and thus knows which Blocks are being
>retrieved? Your design doc specifies that you are lacking
>an incentive for creating large numbers of such Pseudony-
>mousServers, thus the attackers would be the only ones to
>have a motivation to offer such "free" services.

We don't trust "PseudonymousServer" at all. We assume it's already
p0wned by hackers or legal orders, you even don't need hack them, you
just stand outside the datacenter and simply eavesdrop their network
traffic because all traffic for "PseudonymousServer" is over http 

We only trust the anonymity network for anonymizing user's connection to
"PseudonymousServer". 

 

Links:
------
[1] http://secushare.org/scalability
[2] http://secushare.org/pubsub
-- 
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