Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It makes more sense in the context of a larger hypothetical infrastructure. If BitTorrent clients also had the option to publish their open port as a Tor hidden service, then they could register with a tracker that's also a hidden service, entirely over Tor; and then use the tracker to discover the Tor hidden-service addresses of other BitTorrent clients to connect to.

You could also run the BitTorrent Kademlia DHT on top of Tor, without any explicit tracker needed; just with Tor hidden-service BitTorrent client nodes publishing the hidden-service addresses of other client nodes to the DHT ring.

(I often wish that the Tor overlay network was IPv6-based; then "hidden-service addresses" could just be IPv6 addresses in a particular IPv6 public subnet, reserved to represent the Tor overlay network. Then client software wouldn't need to know anything about Tor in order to take advantage; making a client "only operate over Tor" would just be a matter of giving the client an IPv6 subnet mask to restrict what it was willing to connect to; or putting it in a network namespace that was so-restricted.)



I have toyed with DHTs successfully over Tor and it works work fine, but that's just peer discovery. If large data transfer doesn't go over Tor, you're still exposing your IP. If large data transfer does go over Tor you're potentially harming the network (even if it's just to onion service) by over using relays (and Tor actively discouraged BT use over the network). There are alternatives like Tribbler, but none popular enough.

Also onion service v3 addresses, which are entire ed25519 public keys, won't fit in an ipv6 address (haven't checked base 32/36/whatever for v2 onion addresses, but surely also won't fit in, say, a /64).


If the tracker itself is also on Tor, you don't need exit nodes, which are probably the most limited resource in the Tor design due to the legal challenges of running an exit node. And while normal Tor clients use a 3-layer design, a reduced number of layers might be good enough for torrent users. If the torrent client participates in the tor network, that would also help.


does tor’s problem with large amounts of data stem from a lack of operators or the nature of tor itself?


I believe a bit of both. I'm no expert on it, so my response here may not be completely accurate.

Tor relays, while more numerous than exit nodes, are still limited (we're discussing a custom onion service communication setup here, not using Tor for general purpose BT which would use exit nodes). Anyone can run one, and please do so if you have good bandwidth each way. Relays are opt in because not only does it open you up to lots of bandwidth usage, but Tor shouldn't default to running a relay for those that may be philosophically opposed. Relays pass all data through anonymously and encrypted, but some still may not feel comfortable doing it. So there are limited operators.

As for the nature of Tor itself, to keep both the client and onion service operator anonymous, they communicate through a rendezvous which means a Tor circuit for each side (each Tor circuit is 3 hops iirc). And geographic distance is intentionally disregarded, so it may traverse the world multiple times over.

I have considered running a private Tor network with directory servers replaced with a DHT, forcing everyone to be a relay, and then essentially running a private BT over that, but it'd need significant adoption to be viable. Also, there may be Tor limitations in huge numbers of relays (and definitely issues with slow relays), I haven't checked. Finally, in addition to traffic analysis attacks that always exist, it is believed iirc lately that federal agencies are sitting on Tor exploits (granted may only be for exits and/or Tor browser).


wow this is pretty ingenious. the only problem is that i think tor has traditionally been a low-bandwidth network?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: