[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] [tor-talk] Design of next-generation Tor systems

From: carlo von lynX
Subject: Re: [GNUnet-developers] [tor-talk] Design of next-generation Tor systems
Date: Sat, 2 Jul 2016 13:43:26 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

Discussion redirected from tor-talk...

----- Forwarded message from Aymeric Vitte <address@hidden> -----

Date: Sat, 2 Jul 2016 12:17:26 +0200
From: Aymeric Vitte <address@hidden>
To: address@hidden
Subject: Re: [tor-talk] Design of next-generation Tor systems
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101

Le 01/07/2016 à 14:02, carlo von lynX a écrit :
> Just thought.. strange.. Aymeric never bails out of a discussion,
> and guess what, I overlooked his reply! Here we go.

Maybe we can continue off the list since the discussion is going into
specific details not related to Tor

> On Mon, Jun 27, 2016 at 01:00:14PM +0200, Aymeric Vitte wrote:
>>> Do you know of any other technology that does so with comparable dedication?
>>> Is the spy detection for bittorrent that you implemented (and mention
>>> further below) similar to this?
>> Probably it is, but as stated I did not understand very well the
>> presentation, is there some paper or more detailed document about it?

I did read the paper before and looked at the presentation again. It's
very different from what torrent-live (securizing the bittorrent DHT for
the users' privacy but inherently, if used correctly, the bittorrent DHT
already secures the routing for attacks described in the presentation)
and Convergence are doing (explained here but for
Convergence you should replace the notion of file hash by the notion of

In gnunet, when the DHT is used the path for data goes through the node
that stored the data and as far as I understand the ID used for the
nodes in the DHT is the peerID of the nodes (not the same in Convergence
the DHT nodeIDs are the fingerprint of their temporary onion keys, not
their long term peerID), I find it a bit strange since it might be
possible for a node to force the traffic to go through him for a given
peerID (not easy since it cannot choose his peerID but still possible),
but probably this is foreseen, and the path is then a bit "indirect"
too, but why not, will keep this in mind too

>>> Hm, I have a feeling you are describing how gnunet works. Nodes that see
>>> each other keep on communicating to each other also after a restart, but
>>> whenever a new route needs to be discovered, it's time to use the DHT
>>> with the hardened CADET technique. This way it can cross network boundaries,
>>> reach into censorship-friendly countries, operate over mesh networks. That
>>> extra post-broken-Internet capability does not make gnunet less efficient
>>> over the broken Internet.
>> It's similar indeed, I believe each system designed for
>> privacy/anonymity have similarities, maybe something different with
>> Convergence/Peersm is that no direct routes are established toward the
>> peers and data are relayed by rdv points to which the peers are
>> connected via two Tor hops, but one might finally consider that the
>> routes through the rdv points are direct ones, another difference is
>> that peers do not advertise themselves in the DHT, others are doing it
>> for them, one idea behind this (other than countering sybil attacks) is
>> to make sure that the peers cannot freeride
> Interesting, I think gnunet does it differently.. there's some game
> theory in there. But that's outside my competence scope.

I don't remember having seen a lot in design papers regarding
freeriding, that's at least as important as classical attacks,
freeriders can just stop the network, for example if a lot of people
were to use torrent-live then the bittorrent network would just stop working

>>>>>  Also why do people even
>>>>> think of using an insecure file sharing tool (Bittorrent) over an
>>>>> anonymizing network that isn't designed for it if they can use a
>>>>> file sharing system that is designed to be anonymous? gnunet-fs works
>>>>> great from what I've seen...
>>>> gnunet-fs has probably not 200 M peers and associated content, probably
>>> Tor also doesn't have 200 M bittorrent peers. If those peers are all
>>> outside of Tor, then what's the point? Is anonymity only for a few?
>> I did not get this, what do you mean? What peers outside of what Tor?
> You are alluding to bittorrent's 200 M peers, right? Well, those are
> on clearnet, correct? We can expect that Tor would not be able to
> scale to handle them all, it can only help some freeloaders cover
> their identity.

Yes but as we know this does not protect anything

>  gnunet-fs has not seen much popularity but it has
> been tested in simulations on university supercomputers with some
> million virtual users.

Ok but I guess the virtual users don't have the content that the non
virtual users are looking for

>>> Yes. At first it may make sense to play lego and put two things
>>> together, one for the file sharing and the other for anonymity.
>>> But it doesn't scale up.
>> Neither works and/or achieves its goal, perfect example is
> You are announcing a bigger scandal than the unwillingness of WebRTC
> developers to close their deanonymization loophole? Well, let me
> know when "More to come" is replaced.

Bigger I don't know since we are talking about the bittorrent users here
but serious yes, maybe "more to come" will come, this is going together
with the study, and
this is for sale at least to fund this more than two years work
(scandalous, I know... should be free of charge of course)

>>>  Or maybe it is just a question of patience
>>> at the expenses of Tor's relay donors.
>> Maybe if one day we can add Tor nodes apart from the centralization
>> system (like inside browsers as Convergence is proposing), if not it has
>> to be separated
> But then you are not using potential synergy of multicast and onion
> routing. If thousands of people are participating in a distribution
> tree, is it really necessary to have full-fledged OR between each 
> distribution point? I think the anonymous multicast papers have
> figured out more efficient ways.

Is gnunet really multicast? The distribution tree is composed of rdv
points and messages from one point to another go through different paths
composed of rdv points

Get the torrent dynamic blocklist:
Check the 10 M passwords list:
Anti-spies and private torrents, dynamic blocklist:
Peersm :
node-Tor :
GitHub :

tor-talk mailing list - address@hidden
To unsubscribe or change other settings go to

----- End forwarded message -----

  E-mail is public! Talk to me in private using encryption:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]