Re: [tor-talk] Cryptographic social networking project

[carlo von lynX <lynX@xxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Jan 17, 2015 at 08:42:44PM +0000, contact@xxxxxxxxxxxxx wrote:
> If attackers break ciphers one decade later then Tor's forward secrecy
> is compromised even for any collected forward secure operation today. 

Should a way to break ciphers be developed, it is likely it will come
at an execution cost. It makes a huge difference if you have been using
PGP or TLS with off-the-mill ciphers like pidgin's, or if you have been
using forward secret ciphers. It's likely the forward secret stuff will
not be financially convenient to decrypt, at least for a while longer.

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

Word.  :)

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

Ok. This lesson is pretty important to learn. It is a big warning sign
to anyone who thinks he's solved the problem by choosing a federation
server with a .onion interface. Even worse, people that build
complicated new interserver protocols sticking to the old paradigm.

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

Oh no, don't tell me you are not familiar with the Bittorrent
architecture and why it has been so successful. I was trying to
make it easier to grasp since generic multicast isn't so generally
known. It goes beyond the scope of this list if I try to elaborate
why a multicast distribution tree structure is massively more
efficient than a unicast round robin (= "pressure on server").
Trees are what make it possible to have a billion people fetch
a torrent from a single uploader, or to have a billion people
hang out on Facebook. Without a distribution tree, only radio
broadcast can come close. I think I have explained multicast
in my part of the http://youbroketheinternet.org/#stallman video.
That's an otherwise totally worthwhile video with Christian 
explaining GNUnet, @ioerror and RMS saying very wise things.

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

Those nodes that are part of the distribution tree simply keep
some of the traffic they have passed on in a local cache, as much
as they like. This allows for leaf nodes to arrive late and pick 
up what they missed without anyone else even finding out they had
been offline. Should that cache be not enough, then the owner or
any recipient of a channel may have the history of past messages.
Depending on the purpose of the channel, this may be useful or
intentionally disabled.

> >Is social networking all about hi-res pictures and movie sharing?
> 
> not all but most of the expensive part is that

Only if we intend to combine social networking with file sharing,
which - if everythings works out well - might actually happen. We
would however still make everyone quite happy should we provide the
regular Facebook/Twitter-like experience with reduced size pictures,
four lines of description and a link back into the world wild web.


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