Delivery-Date: Sat, 17 Jan 2015 15:42:58 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 4460E1E0693
	for <archiver@seul.org>; Sat, 17 Jan 2015 15:42:57 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 9CC2732F95;
	Sat, 17 Jan 2015 20:42:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 72BE632F8F
 for <tor-talk@lists.torproject.org>; Sat, 17 Jan 2015 20:42:47 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ttlTrbbb6lzQ for <tor-talk@lists.torproject.org>;
 Sat, 17 Jan 2015 20:42:47 +0000 (UTC)
Received: from lmpwn (unknown [IPv6:2602:ffe8:300:1::eafe:be1c])
 by eugeni.torproject.org (Postfix) with ESMTP id 420F532EDD
 for <tor-talk@lists.torproject.org>; Sat, 17 Jan 2015 20:42:47 +0000 (UTC)
Received: from cp.lmpwn.com (localhost.localdomain [127.0.0.1])
 by lmpwn (Postfix) with ESMTPA id 959E02A8017C
 for <tor-talk@lists.torproject.org>; Sat, 17 Jan 2015 12:42:44 -0800 (PST)
MIME-Version: 1.0
Date: Sat, 17 Jan 2015 20:42:44 +0000
From: contact@sharebook.com
To: tor-talk@lists.torproject.org
In-Reply-To: <20150116162029.GA23750@lo.psyced.org>
References: <20150101232704.GA23396@lo.psyced.org>
 <3030ce38ef21b13317af23b9392c5c62@sharebook.com>
 <20150103131957.GA8051@lo.psyced.org>
 <cc5a4038dbb3b463d991364b93f53cc6@sharebook.com>
 <20150109100855.GA25020@lo.psyced.org>
 <aaa2dc760409a9043009e2091dc04538@sharebook.com>
 <20150112162905.GA20152@lo.psyced.org>
 <efa3fd6addc0610e0ad6c7adeb65bd51@sharebook.com>
 <20150114151457.GA6470@lo.psyced.org>
 <59e8b161eb09c6bfe284ae6f86c62c28@sharebook.com>
 <20150116162029.GA23750@lo.psyced.org>
Message-ID: <b67804fda08535be65faf5ef4e631371@sharebook.com>
X-Sender: contact@sharebook.com
User-Agent: Roundcube Webmail/0.9.5
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Cryptographic social networking project
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

 

>although by the forward secret nature of Tor it isn't even a very worthwhile >exercise even if decryption were feasible

If attackers break ciphers one decade later then Tor's forward secrecy
is compromised even for any collected forward secure operation today. 

>I like that you are using "our" while speaking of the secushare model,
>I assume you are considering joining forces. ;)

Our goal is common so it doesn't matter I join you or you join us, the
outcome belongs to people like any other free software :) 

>>anonymity is a different topic. i'm talking about compromising social
>>graphs. for instance in netflix attack vertices are already anonymous
>>but attackers try match some data from IMDB that gave real identities
>>for patterns to deanonymize similar patterns on anonymized netflix
>>dataset and they really did!

>I'm not familiar with this incident. Do you have some info?

This incident is similar to that Flickr paper that you already saw.
Attackers poll out
real identities from another source (e.g IMDB) then try
correlate their patterns with side-channels of pseudonyms to deanonymize
vertices.

>Did you understand what I said when I mentioned multicast ratchets?
>You maintain the advantages of distributing just one packet across
>the network while at the same time having a differently encrypted
>packet on each node of the tree. If I wasn't clear, please ask - not skip.

I thought you said each vertex get same thing, if they get different
things then it's
better

>>>Of course accessing blocks from a third party server is a trade-off in excessive >>>bandwidth, please. 

>>How much excessive MB/GB/TB it would be in your estimation when we >>download block from server?? 

>As I said it is like having n unicast downloads vs one Bittorrent.
>I don't need numbers to know, that the multicast architecture will
>be more efficient in most use cases, but I am sure research has
>plenty of numbers to offer. Please investigate.

I think you are talking about pressure not bandwidth because 167 friend
download same amount of data from server if they try download it from
Bittorent either, and we don't care about pressure on server.

>As I explained, the multicast network itself does a certain amount
>of spooling - and if you *really* need to recover old data, you
>can still reach out for the other subscribers of each pubsub. We
>also intend to use pubsubs among devices to share configuration
>and serve as each other's backup. If you have a relay that is your
>friend, then it can keep a copy of your backups - so whenever you
>lose your smartphone you can recreate your identity and secushare
>experience on a new one. No need for cloud storage for anything.

So you say that at first glance each pubsub node keep all blocks for all
other friendly pubsub nodes then furthermore we save the block on an
unreliable
Bittorrent network? In my opinion even friends are unreliable however
better than strangers.

>Is social networking all about hi-res pictures and movie sharing?

not all but most of the expensive part is that
 
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

