Re: [tor-talk] Cryptographic social networking project

[contact@xxxxxxxxxxxxx]

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

Yes. i'm glad to hear that you started getting the point.

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

It is possible to use pubsub between Alice's SC's third hop and Bob's RP
but it doesn't improve anything for our application because your pubsub
is a topological multicast mechanism over application layer but what
Alice want send to her 167 friends from SC's third hop is 167 completely
different packet. Multicast is for when she want send same packet to 167
recipient thus pubsub at Alice's SC's third hop doesn't make bandwidth
cost of sending Notifications cheaper. 

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

My estimation was accurate but if tens of millions users supposed to
really install our application then we need more Tor relays because
exchanging 10 MB data with PseudonymousServer by millions of users cost
a lot, Today Tor have thousands of relays but they are all busy to
handle other things, there is no much space left for us. 

Most of people out there think Tor is only for escaping from
totalitarians or buying drugs, they call websites behind hidden services
"Darkweb" that sounds very macabre. Tor team should expand its coverage
on legitimate applications for ordinary users who are not doing anything
wrong or escaping from someone. The only upgrade that really helps is
getting more Tor relays. I don't understand why they don't do PR like
most of other companies. Incentive systems like Torcoin can be a good
start. 

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

Sending cipher-text of "Blocks" via hidden services? I think it would
cost much more for Tor network because hidden service have 6 hop while
downloading cipher-text from PseudonymousServer is done through 3 hop
and also friends hidden service might be offline (when friends are
offline we send Notifications to public pool and whenever they become
online they grab the Notification from pool and download corresponding
Block from PseudonymousServer) but it is possible to optionally send the
cipher-text of post directly to each friend who is online through hidden
service but still user should upload the Block on PseudonymousServer in
order to be able retrieve it in future times because user at client side
have limited storage which means might delete things from local cache or
accidentally lose data on its storage which requires retrieving
cipher-text again from PseudonymousServer. I don't see any security
improvement on doing this because when we download something from server
we trust Tor (if attacker can't deanonymize Tor, server only can observe
numbers of retrievals that is useless when all users approximately have
between 100-250 friends thus each block shows averagely 100-250
retrieval, there is no correlation between blocks), for sending data
through hidden services we still need trust Tor so doing that just
increase the complexity for no reason. 

I don't see any bandwidth consuming problem when Paul says "i agree" as
a comment then encrypt it and upload cipher-text as a block on
PseudonymousServer then send a Notification to Alice then Alice forward
same Notification to all her 167 friends because it cost same amount of
bandwidth for transferring Notifications and same amount of bandwidth
for downloading the block 167 times from PseudonymousServer. Sending the
cipher-text block through hidden services will cost much more than
downloading it from PseudonymousServer because when users download a
block from it they are behind 3 hop but when Alice send something to
friends hidden services, there is 6 hop in between. 

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

I think it's better spell the question of choice of trade-off like this:
do we want forward secrecy for sending each Notification to each friend
when we only use Mceliece cryptosystem for asymmetrical encryption? or
do we want forget about group PQ forward secrecy by encrypting the
Notification using a common secret (or using Attribute-Based Encryption)
that is same for all friends to be able multicast the cipher-text value
which will be same for all friends? The answer is very clear when
security is priority and sending 167 Notification in size of 60 byte is
very affordable. If we decide switch to another strategy, it will be
easy by telling a common secret to all friends using a "Notification"
that a specific "Mark" at its beginning declare what is going on (if
desired "Mark" is not defined in application yet, we can ask users to
update application with a new version that understands the "Mark"), but
we won't change our strategy. 

I don't understand why you involved block storage cloud in the questionâ
it have 100% efficiency and have nothing to do with cryptography. 

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

To establish a PQ forward secure key between Alice and Bob, Bob sends a
Mceliece public key (that is 200 KB in size!) to Alice and she use it to
encrypts a random symmetric value then send cipher-text to Bob then he
removes his temporary Mceliece private key. That symmetric value is a
forward secure key. What Alice have for Bob as forward secure key, is
different with what she have for Bill. If you say there will be a
channel between Alice with her friends, the only thing we can do is to
ask Alice send one small Notification to all 167 friends that declares a
symmetric key for encrypting that channel (let say channel is a time
epoch like 6 hours period) so when Alice want send more notification to
her friends through same channel, she will encrypt them by channel's key
and generate same cipher-text for all friends that can be multicasted.
But the real problem is that multicasting is not metadata friendly. 

in pubsub, constant connections even between pseudonyms might reveal
some parts of social graph, what I proposed as Hybrid hidden service is
discontinuous and packets traveling from SC's third hope to RPs don't
look relevant to each other, there is no way to draw a social graph
between one sender and several RPs because when an OR sends 167 packet
to 167 RP, an observer in between can't separate these packets are from
same person who sent them to all those RPs, or 167 different person at
that OR sent those packets to RPs in a linear paradigm as each packet
looks random without any connection information. everything changes when
there is a constant identical connection between SC's third hope and 167
RP that makes entire relations between pseudonyms visible to an
observers between them without hacking ORs. 

it's not feasible to protect metadata secrecy on multicasting because
you fundamentally can't send a random packet to each recipient and when
you multicast same value then you enter one-to-many pseudonyms paradigm
which means some social graphs between pseudonymous vertices become
visible to observers in that zone (search social network
de-anonymization papers for more info). 

I think pubsub is a useful tool for a liberal network when everything is
centralized but it's not enough for a secure network when Goliaths are
snooping on everything. 

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

Blocks don't have trade-off on bandwidth. Bandwidth trade-off is for
Notifications. 

We can use twitter's distribution strategy on PseudonymousServer, you
can consider blocks as tweets, how twitter sends a plaintext tweet to
167 different person from different IP addresses who ask it? I guess we
can use same method to deliver blocks to 167 different person who
request it. 

And in our app we limit numbers of friends to ~250 friends, if someone
shares something to millions then probably it's not private. 

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

There might be a lots of volunteers who are willing to donate their
storage for incentives but they are finite not infinite, someday we
finally get ride of them as numbers of blocks rapidly grow without stop
and we should keep all blocks forever. Just search about how much data
people post on social media everyday. 

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

They are gone because the hard disk itself that kept a copy is gone
(pirated movies overflow, memory failures, volunteers running away,
cryptolockers etc) 
-- 
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