On 10/23/18, Iain Learmonth <i...@torproject.org> wrote: >> [from other threads]
>> Bittorrent users > This is an area with a lot of open research questions. As to width, not really. As before, for the forseeable future regarding the cost to generate collisions into 2^80 compared to the planet's population, Bittorrent, over otherwise acceptably resistant overlay networks, simply has no need for stronger authentication of nodes than that. Worst case any bad blocks and bad talkers will be rejected by existing torrent protocols. That's for the public network. Private BT nets (corp, gov, friends, whatever) have other means of restriction, PSK, VPN, etc. And if someone does waste 80 bits of their time colliding your bittorrent address, just generate another onion on the fly and you're back on in seconds leaving them with a nasty electric bill and nothing to show for it. For purely "non exit" use, as with I2P, tor + Onioncat is perfectly suitable to needs of today's bittorrent users regarding node authentication bit width. > as I understand it, v2 Onion > services will not be around forever Again, that's a completely arbitrary talking point based on Tor's mommy coddling of the end user initiative. That's certainly ok, go ahead, push v3 and all the latest advances everywhere, no problem, that's actually a good and noble thing. However it is also *not* a valid excuse to drop v2, which currently backs UDP IPv6 transport, for those users and groups that have done the analysis regarding their own use cases for v2. In fact, given a v2 mode is sustainable not to the detriment of v3 or future vX, such arbitrary statements against v2 end up looking silly. Even if it were detrimental to future architecture it could be refactored to cohabitate with it and for easier longer term support. > while I don't have data on this > I don't believe that there would be enough users to have the momentum to > fork the Tor network. Hard to say the strength. Looking at the numbers of torrenters worldwide, their need for continued operations, the big indexes and trackers now residing in overlay networks, the constant crackdowns against the nonfree copyright subsector on clearnet... if any significant fraction of them woke up, the influx would be more than enough to fork the net for the purpose of a new free haven for torrenting alone. > One thing I have discussed with the IETF Internet Architecture Board > (IAB) in the past is some sort of scheme for IPv6 addressing for overlay > networks. Related RFC: ORCHIDv2 > The direct mapping between the IP address and an Onion service though is > the problem. How do you discover the Onion service public key when you > only have 96-bits of data? That assumes that greater than any given width (from the plausible range of 80 to 125) is needed for all use cases. As before, for bittorrent, and human convo, it's probably not. And for the applications where it is, well, people have been musing solutions on the lists for years, but not devoting time to developing a working solution as a project. > work on v3 OnionCat > or some Onion-native version of a protocol (via some kind of AF_ONION > sockets). "AF_ONION" has been suggested among many other potential solutions. However as said, you're talking major 3rd party work... libraries, compilation, and runtime options added to all software, whereas essentially all software is IPv6 today, or there in near term. Unlike torify and packet redirection, that AF is not a trivial solution. And everyone knows that tor is not and will not be the only overlay. Thus the software world will not accept all that work just for your own little AF_ONION pet. Any AF_* effort would work *only* if it was done as a wide and generic AF_OVERLAY... a library shim that can talk to whatever overlay transports of the day, even concurrently.. And such AF_OVERLAY work, being larger than tor, would rightly likely be homed in independant working group elsewhere. > An interesting fact I learnt recently is that FTP predates TCP > and was actually "ported" after its original development. NCP was dropped as a comms protocol in the early 80's. Perhaps protocol and fundamental design elements of both tor and that of other overlay networks will be dropped for new ones in the near future as well. Nothing lasts forever, and most today's networks aren't very resistant to today's AI GPA. Three hops circuit extension seems dated to defeating other primary attack classes of their day. And today it is very unlikely that advanced GPA is the laughable conjecture of yesteryear. https://en.wikipedia.org/wiki/Packet_Radio_Van https://en.wikipedia.org/wiki/Delay_line_memory > +1 would encourage anyone that wanted to do research in this area. Yes please. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk