[tor-talk] Design of next-generation Tor systems

[Aymeric Vitte]

Le 25/06/2016 à 13:54, carlo von lynX a écrit :
> On Thu, Jun 23, 2016 at 02:08:13PM +0200, Aymeric Vitte wrote:
>>> 	http://cdn.media.ccc.de/congress/2013/workshops/30c3-WS-en-YBTI_Mesh-Bart_Polot-GNUnet_Wireless_Mesh_DHT.webm
>>> 	http://cdn.media.ccc.de/congress/2013/workshops/30c3-WS-en-YBTI_Mesh-Bart_Polot-GNUnet_Wireless_Mesh_DHT.mp4
>> Did not get very well the presentation but OK it is using a DHT designed
>> to be secure
> 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?

>> The question was why using a gnunet system with its own encrypted
>> concepts if you are using onion routing but then you have of course to
>> build something on top of it, so why not using gnunet indeed with onion
>> routing
> The GAP protocol which does the anonymous file sharing over gnunet already
> implements a kind of onion routing - because when it boils down to metadata
> protection it's always about shuffling data around. But multicast, BRAHMS
> (Byzantine Resilient Random Membership Sampling) and the distributed social
> graph will give three new twists to the concept of onion routing - dealing
> with both the central authority and social scalability problems of Tor.
>
>>> Temporary use of Tor's DHT is good, but how temporary can it be if the name
>>> of the onion is all you have to get started?
>> Peersm does not use the concepts of onion or hidden services, peers have
>> long term IDs (probably managed with a blockchain/wot system, TBD) and
>> temporary ones (their nodeID for the DHT based on their temporary onion
>> keys), like Tor relays in fact, peerIDs are stored in the DHT by those
>> who know how to reach them and/or how to perform peer introduction to
>> them, but peerIDs are also directly sent to the nodes they are connected
>> to through the Tor protocol (who then register them in the DHT), the DHT
>> is used only if nobody you are connected to knows anything about the
>> peer you want to reach
>>
>> Some bridges are used to bootstrap the process
> 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

>>> Great minds think alike. I have to bump up looking into your technology
>>> in my TODO list. It has always been in there, but other priorities keep
>>> urging themselves into the foreground, like writing a decent remote
>>> control tool for Tor.  ;)
>> Trying to work on the Convergence project including Peersm, it does not
>> intend to reinvent the wheel but is trying to merge the best of what
>> exist + new concepts
> Again, that is how Grothoff always describes his contribution policy.
> Or rather ideas. He says gnunet-core implements OTR, but actually it's
> more like Axolotl. Yet, the concept is in there - coding it again to
> fit the overall architecture isn't a hindrance. He's got plenty of
> students to do the coding.  ;)  BRAHMS, too, is somebody else's paper -
> but it fits and does the job. Grothoff has even been mentioning DP5,
> but that's because he hasn't yet fully grasped how the distributed
> social graph of secushare obsoletes such a non-scaling approach.
> For multicast a whole plethora of papers is being consulted. So are all
> the scientific foundations of Tor considered when it comes to OR.
>
>> A remote control tool for Tor?
> My little item to keep Android devices in check.
> http://perlpsyc.cheettyiapsyciew.onion/remotor
> It reports when apps "call home". And it allows me to monitor hidden
> services deployed on servers simply by having my chat client hang out
> in the appropriate chatrooms.
>
>> I see things like Ricochet as something like a workaround that cannot
>> scale and use the hidden services for something that it has not been
>> designed for
> Tor-based P2P systems are pretty much doomed to be one-to-one or
> limited to small long-term chatrooms. That's what I mean by 'social
> scalability'.
>
>>>  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?

>> not an interface as easy to install and use than bt clients... people
> Actually it has improvable but ok GUI. It would need somebody to do
> a debian package since installation from source is a pain (unless
> you are on Gentoo or Guix).

A bit like everything starting with a G for normal users :-)

>  
>> are trying to use what is easy and sometimes attempt to protect, by
>> mistake in the case you mention
> 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
https://github.com/Ayms/torrent-live#deanonymizing-the-vpn-peers

>  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

>
>>> I think it works differently with gnunet, but the result is similar
>>> I guess. Maybe Bart's video will empower you to tell us about the
>>> similarities and differences to Peersm.
>> As stated above I did not get very well the presentation (don't
>> understand in the examples how one guy can block the whole DHT for
>> example), Convergence/Peersm DHT is a specific one designed for WebRTC
>> but probably if we want to compare some models for more security/privacy
>> of a DHT maybe https://github.com/Ayms/torrent-live and the study
>> https://gist.github.com/Ayms/79bdfc6ba747fb49503d can be of some
>> interest ("securizing" probably the most insecure one, the bittorrent
>> DHT, and suggesting some changes in the protocols)
> Interesting stuff!
>
>

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms