Re: [tor-talk] Cryptographic social networking project

[carlo von lynX <lynX@xxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Jan 11, 2015 at 11:39:55PM +0000, contact@xxxxxxxxxxxxx wrote:
> "Hybrid" hidden services doesn't exist yet and it's design isn't

Ok, that is an important bit that somehow wasn't immediately clear to me.
You are not planning to use current Tor but you intend to make a relevant
contribution in the code that runs on the relay nodes and elsewhere.

[...]
> hidden services â just one regular circuit serve hundreds of hidden
> services at same RP. 
> 
> My English is bad. But not that bad. 

I may not be lightning fast at understanding your masterplan. That last
sentence says a lot. So you avoid doing the fan out from the original
source but rather employ the relay network by making the third circuit hops
take care of distribution. By "TCP packets" you mean packets on the already
established TCP connections between the relay nodes, yes? Sorry but some 
obvious things haven't been obvious to me. I probably have to look at your 
spec again now that I'm starting to get it.

> >That may not be sufficient, but it is certainly better than doing the round robin >from the sender's node.
> 
> i think there is no way to make it more sufficient if metadata secrecy
> is requirement

s/sufficient/efficient/ ? 

Should the fan out from the third hop to the RPs run into scalability
limitations, that is just the point where our pubsub architecture could 
plug in. It would organize the RPs into distribution trees to avoid
the third hop becoming a bottleneck for very popular sources (think a
Justin Bieber tweet, or a live webcam in Syria).

> don't forget that our priority is security not scalability

We cannot afford to postpone scalability because then we run into the
Diaspora effect: Media talks about us, millions of people switch to our
platform and we only get *one* chance to prove we can handle the load -
if we fail then, people will not come back. And the world badly needs an
alternative to Facebook - not just for a few closed groups.

If your maths suggests this can already work out in the simple way that
you suggest, that is good news. If it suffers from limitations, we may
be able to offer an upgrade - if I understood your distribution plan
correctly.

I have one question left.. but I think I found the answer further below:

Why doesn't it work to deliver the actual content rather than just the 
notification? Isn't the content supposed to be picked up by everyone anyhow?
Isn't it more bandwidth consuming to have an extra service maintain the
data blocks? Especially in the case of small events like Paul saying
"I agree" in a comment to Alice's status update? Or is this only an option
if we were to use a distribution tree instead of doing fan out from the 
third hop? So if we were to plug in our distribution technology in-between
the third outgoing point and the thousands of rendez-vous points, then we
could probably avoid needing a block package storage cloud.

> Notification that Alice want send to 167 friend is same data so she
> should multicast it? first: even if it was same data she still could
> easily handle it without multicasting because 60 byte is very small.
> second: to reach forward security, each Notification is encrypted by
> each friend's forward secure symmetric key thus each of 167
> Notifications that Alice want send to her 167 friends is completely
> different from each others...)

That answers my question on not sending the entire content over
the distribution network. It is a question of choice of trade-off - do
we deal with the pros and cons of a block storage cloud or do we
accept the challenge of implementing multicast anonymity and forward
secrecy for entire distribution channels rather than just single 
recipients. I think none of this is easily answered and it is legitimate
to try out both approaches - what we can do however is to work together 
on the application side of things, as that can be designed in a way to 
work with either architecture.

> completely different (i guess you are misthinking that 60 byte
> >This sounds like a ratchet mechanism. Nothing to do with scalability
> >or am I misunderstanding you?
> 
> yap nothing to do with scalability but it wasn't a ratchet. As I said
> Alice sends packets to RP without establishing a TLS session so an
> observer in the way before RP can simply measure the "cookie" value and
> use it to flood Bob with junk packets. What I explained was an one-time
> cookie that can't be used twice to send something to RP.

Oh okay. In pubsub the subscription takes care of that.

> I'm sure you agree that CPU cycles and storage disks are out of debate,
> the question is cost of network communications. First of all even in a
> complete different topology we still need send 167 different
> Notification because of forward secrecy that force Alice encrypt her
> Post/comment keys by each friend's forward secure key then encapsulate
> them in a Notification (which means Notifications won't be semantically
> same hence there is no way to multicast them). This means if we use a
> Bittorrent like mechanism, we still have to deliver 10KB data for each
> new post that is shared with all her 167 friends in our paradigm. I

That I believe is a possibly incorrect assumption. If there is a pubsub
channel established among Alice and all her recipients, then the ratchet
can be applied to the encryption key of the entire channel rather than
making 167 individual ones. I don't see how even a global active attacker
would be able to de-anonymize the subscriber list even if they managed to
p0wn one recipient and thus get access to the channel key and content -
since they key only protects the content. Unless of course the list of
recipients is part of the content, but then individual ratches become
completely pointless - and frequently the group membership is not a secret
within a group. So here I see great potential of simplification/optimization
of your model.

> don't see much advantage on delivering that 10 KB using Bittorrent, also
> I don't see any serious drawback for sending that 10 KB data through Tor
> either because doing it only increase the bandwidth cost 3x time more as
> same data has to pass through 3 different onion proxy so the total cost
> for uploading that data becomes 30 KB which is absolutely fine. 

Yes, because you accept the trade-off of having all those people
retrieve their own copy of the data block from the block cloud service.
That is the actual bandwidth trade-off here. How much does it cost to
have a million people fetch the latest tweet of @ioerror from the block
cloud compared to distributing that tweet using a distribution tree?
We essentially reduce the traffic by one million GET requests and a
million of copies of the tweet being pushed from the block cloud into
the Tor network. We only keep the one million outgoing circuit
operations. That should make quite a difference in scalability.

> in my opinion our own project is the most robust approach so far which
> really aims at making a secure and practical social network. I remember
> several other approach that catastrophically failed to do that. One of
> them labeled as "Diaspora" (with distributed-ish mentality) got a lots
> of attention but eventually its developers designed it fundamentally
> insecure and impractical. 

We had very exciting debates on the "gnu social" list in 2010 when 
Diaspora was just starting. The man behind the defunct project "GNU
social P2P" made me change my mind a lot on architcture back then
and heavily inspired secushare. We both asked Diasproa to take our
views into consideration - they originally promised and actually
implmeneted Diaspora in a way that each user has her own PGP identity,
but the idea of having everyone run a complete ruby on rails instance
on their personal devices was of course unrealistic and was archived
sometime later. And then the inevitable followed: The broken federation 
model once again failed to scale and frustrated the new hopeful users.
Also buddycloud ran into scalability issues, but they are not talking 
about it in public. It is really tragic that scalability failures aren't
properly analyzed and documented.

> >Yes, but it doesn't provide tree distribution.
> 
> there is no need for tree distribution

Depends on how much you want to change the world.

> >That part of the model doesn't seem to be a problem with me, although
> >I don't like centralization very much.
> 
> The only centralized part is PseudonymousServer that hosts cipher-texts
> for photos etc and we love to decentralize it but problem is that in
> reality it can't happen, for a large user base we need host new
> gigabytes of data every day that is hard to supply it by volunteers,

That can be achieved by creating suitable motivation. If the social
distance can be computed even for anonymous data, people can sponsor relays
that offer services to first or second degree friends without knowing 
what exactly and who exactly they are working for. The space for ideas
in this field is still vast methinks. 

> also stability is another big problem when volunteers might just
> disappear and users don't like to see their family photos are gone.

Why gone? They should already have a copy on their hard disk.

> Solving stability problem require storing several copy from same data on
> hundreds of volunteer peers who are unable to keep even 1 copy from same
> data 

For the majority of social apps there is no need to hide who the
other subscribers of a channel are, therefore you know who to ask for 
missing copies. If you on top have a pubsub distribution architecture,
then that may keep a certain amount of state available - enough at
least to get the latest updates and incoming mails. Particularely
useful in the 1:1 messaging use case, when you don't want to depend
on both being online at the same time.

> >Maybe we should do social
> >networking protocols over FM antenna or cable TV.
> 
> maybe but don't think about distribution trees for TVs. 

I was alluding to the third of the the three classic distribution
methods.. unicast, multicast and... broadcast. Broadcast does not
use trees, it uses antennas usually.  :)   But I was just kidding.
Multicast is the model that we need for this class of application.


-- 
	    http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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