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