<http://www.onlamp.com/lpt/a/5015> Published on ONLamp.com (http://www.onlamp.com/) http://www.onlamp.com/pub/a/onlamp/2004/08/12/mute.html See this if you're having trouble printing code examples Anonymous, Open Source P2P with MUTE by Howard Wen 08/12/2004 The ongoing battle between users of file-sharing programs and media copyright-enforcement organizations (most notably the RIAA) has seemingly become a daily ping-pong match of lawsuits, threats of lawsuits, countersuits, office raids of commercial P2P services, and soda pop promotional gimmicks encouraging people to download music from legal music downloading services. Regardless of all the threats, intimidation, and spoofed music files clogging networks, P2P services in which users engage in "copyright infringement" (or "file sharing," if you prefer) continue to thrive. Activity on them still far surpasses the traffic of the legal music download sites, such as iTunes Music Store and the now legit Napster. One weakness of the P2P networks, including the infamous KaZaA, is the fact that it's so easy to identify a user's IP address. The Recording Industry Association of America (RIAA) has managed to use such extracted information to subpoena ISPs for the identities of potential defendants. Jason Rohrer has devised what could be the next technological headache for organizations like the RIAA: a P2P system that can mask the identity (or, at least, the IP address) of each user connected to it. Figuratively, he's done it by letting out the ants to ruin the RIAA's picnic. Rohrer, a 26-year-old programmer from Potsdam, New York, found inspiration in the way ants stream toward a food source. From observing the creatures' behavior, he mapped out a networking method that functions similarly - essentially, a shared file is the food source, and clients on the network are the ants seeking the food. He then wrote his own P2P program putting this theory to practice and christened it MUTE. Developed entirely in C++ and released as open source, the program runs on Linux, Win32, and Mac OS X. Figure 1. The MUTE file-sharing program running on Linux. Rohrer spoke with me for the O'Reilly Network, explaining how the ways of the ant could hold the key to anonymity for P2P users. Howard Wen: Give us a basic technical summary: What's the big difference between how the MUTE network works versus the traditional P2P method, such as KaZaA? Jason Rohrer:Traditional P2P networks can best be described as "direct download" systems. Nodes are linked together in a "mesh network," with each node connecting to a small number of neighbors. Certain pieces of information are broadcast and routed through the mesh, such as search requests and results. Downloads are not passed through the mesh - the downloader establishes a new, direct connection to the file source to start the transfer. Of course, a direct transmission means that the downloader needs to know the IP address of the file source. If you use TCP sockets - or UDP packets - properly, a direct transmission also means that the file source can find out the downloader's IP address. The RIAA has demonstrated that, with a subpoena or lawsuit, an IP address can easily be translated into a human name and postal address. In other words, any system that relies on direct downloads is not anonymous, due to intrinsic properties of Internet routing. A MUTE network is very similar in form to a traditional P2P network: MUTE nodes connect to each other in a mesh network, with each node maintaining a small number of direct links to neighbor nodes. In addition to routing search requests and results through the mesh, MUTE routes everything else, including file transfers. Thus, a downloader does not need to know the IP address of a file source, since the downloader never needs to make a direct connection, and a download is routed through the chain of nodes that separate the downloader from the file source. Routed downloads are what separates MUTE from other search-and-download P2P networks. Of course, routed downloads alone do not provide anonymity. Even more crucial is the way that MUTE routes messages anonymously. Each MUTE node generates a random virtual address for itself at startup. Messages are tagged as being "from" one virtual address and "to" another virtual address, though only the sending node knows that it owns the "from" address, and only the receiving node knows that it owns the "to" address. None of the other nodes in the network know which node owns either of these addresses. As messages travel through the network, they leave behind local "scent" - or routing - information for their "from" address at each node that they pass through. For example, if a message from Alice passes through a node, the node records that it has received messages from Alice from one of its neighbors. In the future, if that node receives a message to Alice, it can use this scent to direct the message onward through that neighbor. Each node essentially maintains directional hints about which direction Alice is in, though no one knows for sure which node is actually Alice. HW: What are the inherent difficulties in designing a P2P, or shared network, system, overall? JR: I have developed several P2P applications in the past, including applications that rely heavily on cryptography, so those aspects weren't really a challenge this time around. However, MUTE was the first platform-independent C++ application for which I wanted to develop a true, natively compiled GUI, and this was a major challenge. I evaluated several toolkits, and several factors weighed into my decision. First, I had three target platforms in mind: GNU/Linux, Mac OS X, and Win32. So, I needed a toolkit that supported all of them. Second, I couldn't afford to pay for a toolkit, so I needed a toolkit with an unrestrictive license. Third, I wanted a toolkit that would make use of C++, since object-oriented abstractions seem particularly well-suited for GUIs. These factors essentially ruled out every toolkit except for wxWindows [Editor's note: now known as wxWidgets.] The real challenge came in learning a new toolkit. wxWindows is powerful and feature-rich, but the API is a little quirky. In addition, there were wxWindows build hurdles for the various platforms. For example, my customary Win32 compiler - I sheepishly admit that it was an outdated version of CodeWarrior - couldn't compile the wxWindows library, so I had to switch to a completely different, and unfamiliar, build environment: MinGW. I also had to grudgingly accept that my chosen GUI library was between 2 and 4 times larger than the rest of my application. I detest code bloat, but I really had no choice. The upshot is that MUTE can be downloaded and run natively on both Mac OS X and Win32, even though my development platform was GNU/LinuxPPC. The code that generates and runs the GUI is identical on all three platforms. HW: Have you theorized other aspects of ant behavior that could be applied to effective networking, besides masking a user's identity? JR: In nature, ants tend to find the shortest path between their nest and a food source. Many different paths are traversed at first, but since ants can complete roundtrips more frequently on the shorter paths, the shorter paths receive more traffic and thus more pheromone scent, which in turn leads to more traffic - ants move toward the strongest scents. Eventually, the scent on the shortest path is so strong that all of the ants travel along this path. MUTE's ant-routing also discovers "short" paths between a sender and receiver. However, the fast roundtrip time is what makes a path attractive to MUTE messages. In low-traffic situations, the fastest path will often be the shortest one with the fewest hops. As traffic increases, however, a short path may become slower if it is overloaded, and a longer path with less traffic may be faster. Thus, using only local routing clues, MUTE can automatically balance load throughout the network and avoid congested routes. Of course, you only need this kind of load-balancing if you are routing, and routing only makes sense if you are trying to protect anonymity. While load-balancing is a nice feature and will help MUTE's scalability, it is by no means a standalone selling point for MUTE. In other settings, such as ad-hoc wireless networks, ant-based routing is very attractive and heavily researched. Because MUTE is built as an overlay network on top of the TCP socket abstraction, its ant-routing cannot be used out-of-the box to improve performance in an ad-hoc network. However, MUTE can be seen as a good research platform for exploring the properties of ant-routing, since it is one of the first widely deployed networks to use it. HW: What are the limitations of MUTE? Does it scale up well in performance compared to the other P2P methods? I've read theories suggesting that MUTE might not be able to handle the load if the number of users on it is too large. How many people would you hazard to guess MUTE can effectively serve, in its current version? JR: If you want uploader/downloader anonymity, you simply cannot use direct downloads. Indirect downloads always involve a substantial performance and scalability hit. Even if you ignore the effect on overall transfer speed, you still have at least one additional node involved in each download, which in turn increases the load induced by each download. For example, suppose you have a direct download network of 100 nodes that can support 50 simultaneous transfers - half the nodes are uploaders and half are downloaders. If you now force each transfer to involve an additional intermediary node, while keeping similar bandwidth constraints, you can only support 33 simultaneous transfers: one-third uploading, one third-downloading, and the other third relaying. I will claim that using a single relay or proxy for each transfer doesn't provide enough anonymity. How can you trust your chosen proxy? What if the adversary happens to be operating the proxy that you choose? The same holds true for any system that uses fixed number of proxies for each transfer. If all transfers use two proxies, and you happen to pick two "adversary" nodes to proxy your transfer, your anonymity is compromised. MUTE uses a variable number of intermediary nodes for each transfer, with the network topology dictating how long each transfer chain is. No matter how many nodes in a transfer chain are controlled by the adversary, the adversary can never be sure that it controls all of the nodes in the chain. Thus, the adversary can never obtain the identity of the uploader or downloader with any degree of certainty. Since there is no fixed limit to how many nodes a MUTE transfer can pass through, there is also no limit on how much load is induced by a transfer or how slow that transfer will be, and this is where the scalability concerns arise. Each additional user in the network is likely to initiate additional downloads, which will each increase the load on the network. Of course, if you want decent anonymity, you must make this kind of tradeoff. To answer questions about how well MUTE will scale, we need to answer other questions first: How slow must a transfer become before it is considered useless? How much bandwidth will the average user dedicate to the MUTE network? How many downloads will each user be requesting? As an extreme example, consider the case in which no one is downloading anything: MUTE can scale limitlessly. At the other extreme, if everyone expects fast transfers and wants to be downloading 100 files simultaneously, MUTE won't scale beyond a handful of users. Also, I think it depends on how much users value anonymity. A slow anonymous download may be more valuable than a fast download that could land you in court. The same tradeoff operates for quantity: one anonymous download a day may be more valuable than 100 non-anonymous downloads. As an example, we can assume that a transfer is worthwhile as long as it is coming in at over 5KB/second. If we assume that everyone has a cable modem with a tight upstream bottleneck, then each node can handle relaying or uploading about three files simultaneously. Next, we can assume that each download passes through four intermediary nodes on average. If we have a network of 1,000 nodes, then we can support at most 600 simultaneously downloads at decent rates - each download taxes the upstream bandwidth of five nodes, and each node can handle being taxed by three simultaneous transfers. Of course, these calculations change as the assumptions change, but we have just laid out assumptions that would suggest that MUTE could support 60% of its users downloading one file each at worthwhile rates. As the percentage of downloaders increase in this network, the download rates would decrease throughout the network. With the above assumptions, each additional node contributes three transfers worth of bandwidth, but would consume five such units of bandwidth if it were to download. If we reduce the worthwhile transfer rate to 3KB/second, then we achieve a balance: Each additional node can request a download, since it contributes the same amount of bandwidth that its download consumes, so MUTE could support 100% of its users downloading one file each. If users curb how many simultaneous downloads they request and are content with the resulting transfer rates, then MUTE can scale limitlessly. However, if everyone else is "playing nice," you can increase your personal gain by initiating additional downloads for yourself and abusing the network. Keeping this kind of greed in check is difficult, especially in an anonymous network. HW: Could the MUTE technology be used for other things, besides file-sharing? JR: Before I even thought about applying MUTE to file-sharing, I wrote modules that performed anonymous chat and web-serving over MUTE. Given the current legal landscape, the file-sharing problem was much more pressing, so I have completely switched gears to focus on that. However, MUTE can certainly be used for other anonymous communication applications. HW: What features do you plan to add to future versions of MUTE? JR: I have always intended to keep MUTE simple: It provides anonymous file-sharing, and to my knowledge it is the first application to do so. I want to avoid having MUTE be a catchall for the latest, snazziest file-sharing and user-interface features. I have been improving the robustness of download retries to ensure that downloads can weather traffic spikes and routing problems without failing unnecessarily - several user-submitted patches have been very helpful here. I am also adding a few simple user-interface elements that make MUTE nicer to use, such as a user-submitted patch for better upload statistics. Once MUTE is a solid, usable, and comfortable file-sharing application, my work will be done. Those who want all of the fancy, trendy features can start their own project, add the features, and release their own version of MUTE. My contribution is anonymous file-sharing. HW: Do you need volunteers? What skills and contributions do you need the most? JR: I have been looking for people who have an idea for a feature that can be added to MUTE in a modular fashion, with a clean API separating it from the rest of the MUTE code. HW: What advice do you have for those who might want to modify the MUTE source? JR: MUTE is a layered architecture. The bottom layer is a secure socket implementation that is used to encrypt the contents of neighbor connections. Above that is the MUTE routing layer, which features a very clean API for controlling a MUTE node and sending or receiving messages through it. The file-sharing layer is built on top of the routing API, and it has a clean API of its own, which supports various file-sharing operations, like searching and downloading. The user interfaces are built on top of the file-sharing API, and two are included in the source: a text-based interface and a wxWindows GUI. If you want to build your own communication service on top of MUTE routing, I would suggest taking a look at the routing API. If you want to build a new client for file sharing - for example, a platform-specific GUI, then the file-sharing API will be useful. Understanding these layer APIs will also help you to modify the existing MUTE client. HW: As a programmer, what are some of the things you've been learning as you've been working on MUTE? JR: I have been programming for years, but my coding techniques improve every day. I'm always looking for more elegant ways to do things, and looking back at last year's code can be frustrating. I find the same to be true for any creative process, including writing, visual arts, and music: Since you constantly improve, your past work feels particularly shoddy in retrospect. My coding has improved in many subtle ways that I cannot necessarily put my finger on. In terms of more dramatic changes, the use of a layered architecture has made the MUTE project very easy to manage and understand. I have never used a layered architecture before, but I plan to use it in the future. HW: Have you considered the legal ramifications of what you're doing and prepared for any possible legal action? As everybody knows, the RIAA and its international counterparts have been going after both users and developers of P2P software quite aggressively. JR: So far, these organizations have confined their attacks to corporations that are peddling P2P and making money off of it. There is no precedent for a suit against an individual P2P developer who is releasing non-commercial, open-source software. Selling a product that helps people break the law is very different from giving it away. Furthermore, there is no explicit law against software like MUTE. That said, I could always be the precedent, and I am ready for anything. I believe that coding is part of my right to free speech, and I also believe that I have the right to encourage people to break an unjust law as a form of social protest. Many people look at the MUTE web site, which refers directly to how MUTE circumvents the RIAA's spy tactics, and say, "Whoa, friend, I would be careful if I were you." Sure, many other P2P developers and companies blatantly lie about what their software is for, but I refuse to lie. You can write a book that encourages people to break the law - for example, The Anarchist Cookbook. Why can't I write a web site that does the same thing? To be honest, I think it is highly unlikely I will be sued, but only time will tell. HW: It's inevitable that a third-generation P2P service is probably on the horizon. Will you be so bold to say that yours, MUTE, is it? JR: Whatever the third-generation P2P system will be, it will certainly be anonymous. All past P2P innovations have been spurred by the legal tactics of the day. I don't see why the next leap will be any different. MUTE is probably more of a vanguard than the be-all, end-all third-generation P2P system, much like Gnutella was the vanguard for the second generation. Other P2P developers may be inspired by MUTE and start thinking about how to make P2P anonymous. Unfortunately, if history repeats itself, the most popular third-generation network may be owned by a corporation that was ultimately inspired by my work on MUTE. It would be nice to see an open-source and open-protocol network win this round, if only to ensure that at least one open-source application was on the majority of people's desktops. Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others. -- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'