Re: [tor-talk] Cryptographic social networking project

[contact@xxxxxxxxxxxxx]

>It may be the language, but I feel you are talking about completely
>different things than the ones I pointed out. Feel free to throw all
>your estimates at me, but it doesn't make me think you solved the
>systemic problem of addressing an exponential challenge with a linear
>solution. You summed up bandwidth as if the useless redundancy of 
>the content on the network was irrelevant. I believe it adds up and
>in all cases I saw where this was underestimated (round robin unicast
>distribution by HTTP or XMPP for example) it has subsequently failed
>to scale.

I just proved that Notifications are affordable in mass scales. if you
think i missed something then show details

>That sounds completely different to the architecture you described
>on the website. You say Alice no longer establishes circuits to each
>friend in order to deliver notifications? Then how do the notifications
>travel. They all go through a central cloud service? No, you mean
>something else...

On website I didn't talk about details of hidden services themselves,
even Tor team admit that hidden services need more care. 

"Hybrid" hidden services doesn't exist yet and it's design isn't
suitable for serving something like an HTML website but follows same
concept, it let Bob introduce himself to Alice without revealing his
location and hides their connection from outsiders, which will work
great for social networking applications. In Tor hidden services today,
beside a lots of other things that Alice have to do before telling the
rendezvous point to Bob, the connection between Alice's circuit with
Bob's circuit at rendezvous point require establishing a TLS session,
but as I said in hybrid hidden services there is no need to establish a
TLS session between Alice's SC third hop and Bob's RP because they
already have keys for each other, and also there is no need to use a
different SC to send something to Bill's RP, whenever Alice have a
notification for Bob, she ping his RP and if Bob is there then send the
packet that is encrypted by RP_KEY directly to it as a TCP packet. Of
course Bob before that tells everything to RP and make it ready to
accept her packet. if someday Tor developers really implement hybrid
circuits, it would become a little bit more complicated than I
suggested, I just tried clarify it in a simplistic way to let you
understand that nothing go through a central could service to provide
hidden services â just one regular circuit serve hundreds of hidden
services at same RP. 

My English is bad. But not that bad. 

>So Alice reopens circuits to each of her friends all of the time?
>In order to deliver a notification she does 167 circuits - sequentially,
>thus with a tangible latency?

No! Alice have a regular circuit that I called it SC, its third hope can
send TCP packets to hundreds of RPs in less than a few milliseconds.
When Alice knows what is Bob's RP, she don't do anything with it, it's a
local knowledge, she only touch RPs whenever she want send a
notification to them and when she wanna do that, first do a trivial TCP
handshake with each RP which almost add nothing to size of 60 byte
Notification itself that i estimated for you in previous email. So there
is not 167 circuits at Alice side, even when she send something still
she won't establish 167 circuits with friends. I explained it very
clearly 

>Nothing of this explains how you avoid maintaining 167 circuits just
>for Alice instead of efficiently delivering one message from Alice
>to 167 people, using a suitable distribution tree network. It's like
>I'm talking apples and you answer cucumbers.

I answer apples but you read them as cucumbers. I demonstrated that
Alice won't maintain 167 circuits by one Hybrid hidden service but you
say "nothing of this explain how you avoid maintaining 167 circuits just
for Alice". 

Alice efficiently deliver Notifications to her 167 friends (It doesn't
make any problem for anyone, neither friends nor Tor relays) and
Notification is not one message, each Notification for each friend is
completely different (i guess you are misthinking that 60 byte
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...)

>You are using a circuit to talk to a rendezvous point without actually
>establishing a circuit? Now you are venturing into details of Tor
>protocol that I am not familiar with. If Tor let's you optimize some
>things here that is cool, but that still doesn't make a distribution tree.

There is no need to optimize Tor protocol, relay operators are using a
client software that is programmed by Tor, a little bit change on that
allow us talk with relays (send packets) as described. It doesn't
break/change anything on Tor specs or current Tor hidden services. And
we don't need distribution trees in here. 

>The rendez-vous point maintains state for Bob? Is that an extension you are >proposing to the Tor protocol?

yes

>So the RP is in charge of actually distributing the message?

RP is Bob's receiver (which listens to all friends not just Alice),
Alice have a circuit that i named it SC, its third hope (which don't
have an acronym yet) is in charge of distributing packets to all friends
RPs ...

>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

don't forget that our priority is security not scalability

>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.

>Bandwidth isn't the answer. Not even Google, Facebook or Twitter solve
>the distribution problem by bandwidth, even if they are the ones that
>could afford to cheat this way the most. Yet, they have distribution networks.
>If Alice sends 167 individual notifications, she is not distributing.
>Distribution should happen as close as possible to the recipient.
>If a guard node receives a notification and distributes it to 24 final
>recipients that have subscribed for it, that is an efficient distribution
>plan. It implies relay nodes maintaining state about distribution trees
>and a different plan for achieving anonymity.

If debate is about scalability then we are only talking about costs that
are categorized as 1-bandwidth 2-computation 3-storage. We can't talk
about latency or topology for scalability here because if they spend
something then it shows itself on our bandwidth costs. When data
transfer is the case we should ask how much bandwidth it cost for
routers? when data processing is the case we should ask how much CPU
work it cost for operators? when data storing is the case we should ask
how much space it cost for databases? 

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
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. 

For notifications as I said we can theoretically serve even millions of
users by a few thousands Tor relay so there is no need to change it and
changing it will become truly challenging to make it secure as it is
today by aid of hidden services. 

>To this part you can apply cloud technology, so that should work. 

Yes for PseudonymousServer we can apply any cloud/broadcast technology
that we desire 

>Both your assumption (friends = routers) and your deduction are wrong.
>You may want to watch some gnunet videos on http://youbroketheinternet.org [1]

Sorry for that I didn't looked into your website carefully. 

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. 

>Yes, but it doesn't provide tree distribution.

there is no need for tree distribution

>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,
also stability is another big problem when volunteers might just
disappear and users don't like to see their family photos are gone.
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 

>Yes, I was pointed to "alpha mixing" - a brilliant paper that has been
>lying around unimplemented since 2006. Also noticed some recent
>conversations on the topic that my grep for traffic shaping failed to find.
>Tor should focus on financing these developments ASAP.

I believe if a secure high latency onion network in the future break the
news then we can easily migrate to it without breaking anything in
application or user base. So there is no need to think about anonymizers
today 

>Beyond my area of competence here. I love when cryptographers find
>brilliant solutions I couldn't have come up with, but I haven't seen
>one for mass distribution of data yet. Maybe we should do social
>networking protocols over FM antenna or cable TV.

maybe but don't think about distribution trees for TVs. 

 

Links:
------
[1] http://youbroketheinternet.org
-- 
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