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

[carlo von lynX <lynX@xxxxxxxxxxxxxxxxxxxxxx>]

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?

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

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

> 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).
 
> 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. Or maybe it is just a question of patience
at the expenses of Tor's relay donors.

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


-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/
-- 
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