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

[Aymeric Vitte <vitteaymeric@xxxxxxxxx>]

Hi Carlo, please see the comments/answers below


Le 22/06/2016 Ã 13:46, carlo von lynX a Ãcrit :
> Hello Aymeric!
>
> On Wed, Jun 22, 2016 at 12:41:35PM +0200, Aymeric Vitte wrote:
>> Not a specialist with gnunet (how does peers discovery works with
> I think this talk is very worthwhile in explaining how gnunet works
> and why it is indeed a *replacement* for the current internet, not
> something that needs to run on top of it:
>
> 	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

>
>> gnunet?) but one question can be: if you are using onion routing then
>> why are you using gnunet?
> I don't understand the question. The strategy of peeling onions, be
> it in circuits, packetwise or within a mixed net, is still the #1
> method for achieving metadata protection. See also Paul's post.
> GNUnet does several other things well, but still it makes sense to
> also implement onion routing. But onion routing alone does not
> provide all of the things needed by secushare: 1. one-to-many
> distribution and scalability, 2. sibyl attack resistant design and
> 3. framed application traffic + constant bandwidth usage to defy 
> traffic shaping attacks.
>
> It's the combination of these measures that allows us to leave out
> one aspect when necessary. For example we can afford not to have a
> permanent bandwidth allocation if we have framing and onion routing,
> thus allowing for distributed social networking apps on mobile phones,
> or we can afford to reduce the onion routing for real-time traffic
> if we can segment and mix it with file sharing gossip, this way also
> defeating phoneme detection attacks on voice traffic. Or we can surf
> the insecure web and risk fingerprinting attacks if the stuff then
> goes through onion routes over constant bandwidth channels. Alpha
> mixing would probably help, too, but constant bandwidth is easier
> and already implemented. We have an advantage in synergy if we use
> one big fat tool to replace the broken Internet rather than try to
> have separate tools attempt anonymous real-time and bulk data exchange
> without cashing in on the synergies. And nothing keeps us from 
> securing our best secrets like our political views, commentaries and
> dick pics by using all measures at once.

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

>
>> I would put a bemol on the (generally widely propagated) statement that
>> a DHT is necessarily insecure and not resistant to sybil attacks, in the
> It is a question of how you design the application, but I think I
> elaborated that well in the paragraph.. no?

Rereading it yes but the first read gave me the impression that DHT
systems were excluded

>
>> Peersm case the nodeIDs are temporary and related to the onion keys of
>> the peers (so sybils can not position themselves where they like in the
>> DHT, which from some research is maybe not enough but makes sybils' work
>> difficult for sure), they expire after each session, the DHT does not
>> contain direct information about the peers but what the peers know about
>> others (ie what the rdv points know about how to reach others), in
>> addition the peers are informing themselves directly about what they
>> know (the rdv point to reach this peerID and/or the introduction point
>> to establish WebRTC connections between two peers), the DHT is used only
>> if nothing is known about a peer, so sybils should invade both layers
>> which seems quite unlikely.
> 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

>
>> As a corollary your section "Onion routing the secushare way" is similar
>> to Peersm, as well as the concepts that 3 hops are not required (2 for
>> Peersm), indeed a peer can't know its position in the path, in addition
>> for Peersm the peers are acting as rdv points AND peers, and circuits
>> can "extend" from a rdv point to others (A wants to reach D, B knows
>> from C that C knows how to reach D, the path goes through two rdv points
>> B and C, each point being connected via two hops), so they can't even
>> know if they are serving the data as the first rdv point acting as a
>> peer, relaying it as the first rdv point, or relaying it as the nth rdv
>> point, or serving it through n rdv points
> 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

A remote control tool for Tor?

>> Tor in his current form will never allow to do p2p, as commented here
>> again:
>> https://lists.torproject.org/pipermail/tor-talk/2016-June/041529.html,
> It could work for Ricochet-like P2P messaging, although the APIs are
> too cumbersome I think. When a Tor connection comes from a certain
> person, its virtual IP should resolve to the equivalent onion address.
> That would make P2P operations trivial to implement. Whereas you are
> totally right regarding file sharing.. it is the same point I am
> making in the first paragraph on scalability.

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

>  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
not an interface as easy to install and use than bt clients... people
are trying to use what is easy and sometimes attempt to protect, by
mistake in the case you mention

>
>> the only fact that nodes will not extend to nodes that are not
>> registered in the directories just makes this impossible, but as your
>> onion routing solution or mine show we don't need it.
> 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)

>
> Griffin: tor-talk is frequently a discussion platform for onion
> routing theory beyond the boundaries of what the Tor platform can
> do. Is that off-topic? Do people who design next generation Tors
> need to find themselves a different place to discuss?
>
>

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

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