The Hydra Project received some major coverage today from TorrentFreak and via its page on Digg.

The Hydra Project is a distributed, private BitTorrent tracker framework with goals of user privacy, anonymity, survivability & distributed ratio maintainability.

The initial development of it was motivated, in part, by a high-profile takedown of a very well-known and beloved private BitTorrent tracker in recent months.

The Academic Question

Could a network have been setup such that the torrents, user logins, and user ratios been maintained following the takedown of that single site?

I wanted to see if that would be possible. In the answers below, you’ll see that there’s no 100% bullet-proof solution to this thorny problem, but one can attempt to make a best-effort approach.

Other Practical Applications?

Let’s say you’re the leader of the Falun Gong in China, or some kind of resistance movement against a book-burning, totalitarian regime.

Would there be a way to setup a distributed network to keep your digitized materials and beliefs alive, in the face of threats from these regimes?

It might be a stretch in this case to use BitTorrent and trackers for this, but it’s very doable, and could help keep a network of such content alive and available to dissidents in these kinds of threatening environments.

Questions from TorrentFreak Commenters

To answer a few of the questions from the comments on TorrentFreak:

* All sites in each “federation” or whatever you want to call it, have to trust each other. This is left up to the torrent admins who want to try running a script like this. If they believe that they can trust one another, then they add each other (including the passkeys, domain names, etc) to the list of trusted sites in the network. If you trust someone who happens to work for the MPAA, well, you must not know your friend / fellow admin that well, and I don’t know of a way to get around this threat, really.

* There can be multiple (any X number) of federations. i.e. as from the example, you can have “bacon.org, eggs.com, ham.net, etc” in one federation, sharing torrent / user data. Then another group of admins, with completely separate torrents and data, can get together, and perhaps have a different focus on their content (music, instead of video, for example). This separate network would operate on their own domain names, e.g. fido.net, shaggy.com, lassie.org, whatever.

* It is indeed true that if every single one of the sites gets raided at the same time, the entire network will crumble. It’s easy to make backups, but if the network has lost control of all domain names, then the .torrent files people have downloaded will simply no longer work. (each .torrent file includes multiple tracker URLs, which either contain the IP address or domain name of the servers) Having servers in Sweden, China, South America, etc (one “head” of the Hydra in each) may well be a good idea for the truly paranoid.

Questions from Digg users

To answer a few questions / concerns from the Digg thread:

* Does the tracker still send a list of IPs to peers (via /announce)? Yes, of course. This is part of the BitTorrent protocol. If MPAA / whoever becomes a member of the torrent site and sniffs out peer IPs, this is impossible to stop in any tracker.

However, some of the existing tracker codebases (vanilla, unmodified) stored the last IP address (+ time) for every single one of its users that connected (in the MySQL database). If that server got raided, it would be trivial to go back to the ISPs and associate these users with a cable modem / home address. (perhaps wrongfully, as the RIAA suing grandmothers has shown)

Is THP more secure than this? Yes. Is it immune? No — that’s impossible in P2P. (users can take precautions but if they use their home ISP, then their home IP Address must be shared with others to initiate xfers)

* Will this actually work in practice? I don’t know. It’s a fun proof of concept. It’s up to private torrent site admins to decide if they’d like to try this out in the wild.

The Code

Currently the code is licensed under the MIT License (same as Rails).

More on The Hydra Project

From the Hydra Project page on Google Code:

Goals of THP:

* Maintain user privacy & anonymity at all costs
* Survivability of the overall network in the face of a single or several (not 100%) of the network being attacked or raided
* Distributed ratio and user management across multiple trusted domains (a bit like OpenID, for private trackers)
* Development of the “spec” Hydra Project protocol (implemented in Ruby on Rails) which can be ported over to PHP, etc.

Anonymity and privacy precautions:

* User IP addresses are never stored on disk or the database
* Email addresses are never collected
* Password hashes are stored in the database with a random salt for each password hash (to curb the feasibility of widespread rainbow attacks)
* Uploaded .torrent files are not associated with users
* User information of who seeded/uploaded particular torrents is never stored
* Share ratio information is kept (bytes downloaded/uploaded), but not a list of the actual torrent files
* One requirement of private trackers is to lookup IP Addresses to correlate username (last login from IP) with torrent client IPs
* For this problem we use memcached, which only ever stores the IPs in system RAM

If you’d like to do some hacking in RoR, PHP or python, or have any other questions, feel free to drop me a line at: shantibraford (at) gmail.com