Avoid the RIAA with MUTE

by Steve Mallett

Related link: http://osdir.com/Article202.phtml



As some of you may know some of my passions revolve around P2P, online privacy, and open source apps. I have the privilege of being able to present an introductory article on one of my favorite new applications: MUTE.


This is a mouthful, but MUTE is a cross-platform, P2P, anonymous, and open source file sharing client/network. Keyword: Anonymous.


I'll leave the intricacies up to the program's author who also wrote the article, but if I may whet your appetite with one more buzz word... it uses mechanisms inspired by ant behavior.


I have this running on my iBook when in Linux or OS X, and a windows machine.


I urge you to give it a try it unless you want to end up on a Pepsi/iTunes commercial during the Superbowl. If you know what I mean.

Since the network is new the wealth of sharable material is a bit sparse in places, but give it a chance to grow. Legal pressure is sure to push more and more people off the current popular networks.


15 Comments

osokin
2004-02-24 14:16:36
MUTE and user protection
> I urge you to give it a try it unless you want to end up on a Pepsi/iTunes commercial during the Superbowl.


Steve, I hate to rain on your parade, but this technique was being discussed among Gnutella developers for several years, and still no one bothered to implemented it, as far as I know.


Two reasons for that: first, with this approach the traffic on the net just explodes (and that's in comparison with Gnutella, which has a well-deserved reputation for being a bandwidth hog!), and second, it does not protect you from anything.


According to


http://mute-net.sourceforge.net/howPrivacy.shtml


the military-grade encryption protects the privacy of the MUTE user.


Well, whether the MUTE encryption is military grade or not, you don't have to decrypt it on the source node LAN to prove that this node is providing you with a copy of a file. All you have to do is observe his traffic and match his outgoing packets to your incoming ones after they are decrypted, and it becomes instantly clear that yes, it is this node who sends you the copy of Metallica__Unforgiven.mp3. And if there are no incoming packets coming to this node, case is closed.


And this is just one type of an attack, the one that was foreseen by the MUTE creators.


So without getting too technical, I'm afraid that you'll have to prepare yourself to the role in the Pepsi commercial, after all. Or better yet, lobby for a real compulsory or blanket licensing solution as suggested at


http://www.eff.org/share/legal.php


Or - at the very least - go get yourself some insurance at


http://www.p2pfund.com


Best wishes -
Oso.

jimothy
2004-02-24 14:42:41
Another way
Another way is to stop stealing music.
spaceman
2004-02-24 14:57:44
Another way
Touche; however, that debate is still open.
osokin
2004-02-24 15:36:24
Another way
> Another way is to stop stealing music.


Hmm... Leaving aside the very interesting discussion about whether the word "stealing" is applicable here in the first place, I'm afraid that this approach is not really practical.


From the pragmatic standpoint, it is obvious that what you call "stealing" is going to continue no matter what - the issue here is only how to make it legal and pay the artists at the same time.


And here I really don't see any long-term solutions other than the ones listed at EFF's Making P2P Legal" page; in the meantime, P2PFund might be providing a short-term "bridge solution".

osokin
2004-02-24 16:02:38
Another way
Just for fun, let me try another way to submit these links:


MUTE: Simple, Anonymous File Sharing


Making P2P Legal"


P2PFund


(I wonder who wrote wrote the comment submission code for this page... "Real Klingon programmers won't ever have a need to preview their postings!", right?)

jcr13
2004-02-24 18:50:30
Not clear
All you have to do is observe his traffic and match his outgoing packets to your incoming ones after they are decrypted, and it becomes instantly clear that yes, it is this node who sends you the copy of Metallica__Unforgiven.mp3. And if there are no incoming packets coming to this node, case is closed.


It's not clear what you you mean here. Are you talking about traffic analysis? Are you looking for more data coming out of a node than going in? If you cannot see the contents of packets that are going into a node (because of the encrypted links), then how can you tell that particular outbound packets are being generated by that node, especially with non-trivial, real-world traffic levels?


You see a bunch of packets going in, and a bunch coming out, and one of the packets coming out (to your node) contains part of a Metallica file. Where's the proof of guilt here?


Certainly, if the network were dead quiet, traffic analysis of this kind would be easy (no packets going in, and Metallica packets coming out), but I can assure you that the MUTE network is anything but dead quiet.


Is there something that I am missing here?



In terms of scalability, it is not true that network traffic just explodes when you route downloads. The word "explodes" implies exponential blowup, which is certainly not the case. Each additional download places burden on a handful of nodes (those that route the download), and the burden created by a given download is constant with respect to network size. As the number of simultaneous downloads increases in the network, the overall burden grows linearly.


Obviously, direct downloads and anonymity don't mix, so you have to resort to indirect, mult-proxy downloads, and there is going to be a trade-off. Download speeds will decrease as we move to anonymous networks---there's simply no way around it.


Jason
(the MUTE dev)

osokin
2004-02-25 00:19:55
Not clear
> Certainly, if the network were dead quiet, traffic analysis of
> this kind would be easy (no packets going in, and Metallica
> packets coming out), but I can assure you that the MUTE network
> is anything but dead quiet.
>
> Is there something that I am missing here?


No, not really. You're correct. Like I said, I did not want to go technical, so I provided a very primitive description of an attack in a very simplified situation. Real traffic is much more complex, but so are the real attacks.


Timing attack, for example, tries to establish the correlation between the long packet sequences on the sending and receiving sides. See, for exemple, Timing Attacks in Low-Latency Mix Systems: "...there are a number of known attacks [...] that take advantage of weaknesses in mix-based protocols..." ('mix' is what MUTE technically is). It is hard to protect against this attack, unless you're doing something very special, for example always send constant-rate streams on all the links ("constant-bandwidth padding").


Tor: The Second-Generation Onion Router paper, however, wryly notes: "Volunteers prefer not to run constant-bandwidth padding". In plain English it means that the users are unlikely to use the system that always maxes out their ISP link, whether they need it for something else or not. (Note, by the way, that Tor protocol, for all its sophistication,explicitly refuses to anonymize the P2P environment, since it is difficult to do so when the unknown number of peers might be controlled by the adversary.)


Then there are all kinds of attacks that involve your ISP or LAN. MUTE page mentions one of them, when the traffic on the LAN is being observed. But this was just a passive attack. If you can actively manipulate this traffic, other possibilities open at once. To provide just one example, if all the incoming packets are delayed for some time, then the network really becomes dead quiet, and even the simplest traffic analysis attack can be performed (providing the direct match between outgoing packets and incoming packets on the other side). And if such an "active ISP" attacker decides to play the man in the middle - do not even get me started on that subject...


> In terms of scalability, it is not true that network traffic just explodes
> when you route downloads. The word "explodes" implies exponential blowup, which
> is certainly not the case.


Correct. No exponential blowup, that is. It is bad enough even without it. As you say,


> Download speeds will decrease as we move to anonymous networks---there's
> simply no way around it.


What I had in mind is that the file-sharing networks tend to operate close to the uplnk bandwidth saturation, and the download speed always seems to be among the main users' complaints and concerns. Routing through just two intermediate nodes cuts the average download speed by a factor of three, and I'm not sure that the users will be uniformly happy about it. Especially since their anonymity won't be bullet-proof in any case, right? And making it bullet-proof would require even more sacrifices - constant-bandwidth padding or something equally obscure and demanding.


Alas, today it seems to be virtually impossible to create the network that would be both completely anonymous and practically usable on a large scale at the same time.


Best wishes -
Oso.


P.S. If you see your intended italic in my quotes as really italic, it means that the lower-case tags really worked. Took me three attempts to figure this out.
But if the tags are still visible as bracketed letters, then I'm still not getting it. This comment submission code is really something special... :-)


cflint
2004-02-26 13:42:44
This stuff is crap...
Why can't you just admit you steal music? If someone was stealing your intellectual property or personal property and used something similar, what would you do?


I'm all for security and making it harder for people to mess with my identity and what not, but to use something like this for the sake of stealing is lame.


Sorry your life is so consumed with beating the RIAA. Just buy the music, listen to it and enjoy it.


jcr13
2004-02-26 15:34:57
All bets are off, for sure
And if such an "active ISP" attacker decides to play the man in the middle - do not even get me started on that subject...


If your ISP plays man-in-the-middle, a lot more goes out the window than just your anonymity. How about the security of every HTTPS connection that you make? Even if you get key certificates from a "third party," your ISP can intercept and forge those certificates. How about SSH?


All of the key exchange protocols are useless if you have an adversary that can actually change data on the wire. The only solution would be to exchange keys ahead of time, face-to-face.


So, you have to have a threat model in place before you even start talking about security.

MUTE was designed to thwart the RIAA's spy tactics. That threat model assumes that the RIAA cannot directly manipulate data on the wire or play man-in-the-middle with TCP socket connections. The RIAA can potentially play man-in-the-middle on the MUTE network itself, and that's why MUTE doesn't even bother encrypting routed data end-to-end.


I'm not selling snake oil here---I have been thinking about these details for many months. I believe that MUTE provides sufficient anonymity in practice to protect most users from the real-world privacy threats that they face, including the RIAA.


Jason
(the MUTE dev)

spaceman
2004-02-27 13:42:31
This stuff is crap...
"Why can't you just admit you steal music?"


Arguements are endless, but I'll bite... What if I'm downloading songs for albums I've already purchased. For instance I've worn out two cassette tapes, and one CD of The Smiths: The Queen is Dead. How many physical copies do I have to buy???


etc etc.


"Sorry your life is so consumed with beating the RIAA. Just buy the music, listen to it and enjoy it."


I used to buy music after sampling it from P2P networks. Once the RIAA went nut on people I've opted out of that. I'd like to go back, but frankly, I don't see the RIAA letting up. Two wrongs don't make a right, but neither does doing nothing. blah blah blah.

osokin
2004-02-27 17:16:54
All bets are off, for sure
> MUTE was designed to thwart the RIAA's spy tactics.


Which it does - not much doubt about that. Problem is, what happens if RIAA changes tactics?


> I believe that MUTE provides sufficient anonymity in practice to protect
> most users from the real-world privacy threats that they face, including the RIAA.


This is also technically correct.


First, RIAA does not have enough lawyers to sue "most users". So MUTE or no MUTE, the users are pretty safe.


And second, MUTE user base is pretty small, and RIAA probably won't even bother to sue its users. But it might change its mind, can't it? Other "anonymous" networks have seen this happening to their users.


And when this happens, you'll have to withstand attacks on RIAA terms, not on your terms. You will be facing a fairly creative human adversary. Let me give you just one example:


If I am not mistaken, there are ten connections that MUTE tries to maintain at all times, and they are not explicitly separated into incoming and outgoing. Every five seconds MUTE client checks if it has ten connections, and if it doesn't, it tries to open the missing ones. I did not study the code all that long, so I might be wrong here - then next time I'll have to come up with another attack plan.


But if I'm right, here is how I would attack a MUTE user if I'd work for RIAA (btw, I don't): I would select a random node and start establishing the connections to its IP address from ten different machines. At first, nine other connections would belong to the legitimate MUTE users. But if I would keep pinging the node with connection requests every two seconds or so, sooner or later all ten links would belong to me, and I would be able to do whatever I want with the traffic of this node - see it, control it, send it the requests and observe shipping me the requested files (obviously from its disk), etc, etc.


Then it is just a matter of time to repeat this procedure multiple times and find the node with lots of content - the one that you'd really like to sue. You can do this automatically - an overnight run of the attack cluster can bring you enough defendants to keep the whole law firm busy for months.


Of course, now that you know about this attack, you'll fix that vulnerability (at least if I was right and it existed in the first place :-) But my point is that the determined adversary might be quite hard to fight - and you can count on your adversary being sufficiently motivated to do the things that you don't expect him to.


It is not that your code is bad - it is quite good, actually. I really enjoyed digging through it. It is just that you're trying to protect your user against the things that you think your adversary will be doing, not against what he's actually going to do.


And as you've said yourself, ultimately there are very few truly secure things on the Internet - not HTTPS, not SSH, not any other key exchange protocol without an out-of-band key exchange channel. I couldn't agree more.


That's why I think that the real solution to P2P problem is in developing the content licensing model that would be acceptable to everyone, not in trying to secure things that are really difficult (and maybe even impossible) to secure.


Best wishes -
Oso.



kollivier
2004-02-27 20:47:29
This stuff is crap...

Arguements are endless, but I'll bite... What if I'm downloading songs for albums I've already purchased. For instance I've worn out two cassette tapes, and one CD of The Smiths: The Queen is Dead. How many physical copies do I have to buy???


But these are not the primary purpose of P2P networks, it's an auxillary use. (P2P is not a backup application.) Not to mention this is not the only legitimate alternative you have for getting a backup of your music (why not make one, two, or ten yourself?). So you think it's OK to post Adobe Photoshop or an O'Reilly book on a P2P network in case someone else breaks their CD or damages their book? I'm sure no one else would download it.


I used to buy music after sampling it from P2P networks. Once the RIAA went nut on people I've opted out of that. I'd like to go back, but frankly, I don't see the RIAA letting up. Two wrongs don't make a right, but neither does doing nothing. blah blah blah.


How about radio, web radio, or services like Napster which let you listen to all the tracks, all the time for a small monthly fee? You're not exactly backed into a corner. You're right, two wrongs don't make a right, and neither does doing nothing. So how about supporting a legitimate service which is trying to meet your needs so that they can make it better, and possibly cheaper? Why not trying to compromise a little? Taking the position that you'll only be satisfied with a service that gives you free, unlimited music downloads isn't really that helpful in meeting the needs of those who, legitimately, want to make money from their work. Encouraging people to download more "free" music (or anything else digital) is probably only going to encourage more lawsuits and just adds fuel to the fire. Would you like to be part of the solution, or part of the problem?

choonkeng
2004-02-29 19:56:53
Slow transfer
I will talk no more about security & anonymity.


But from another perspective, I feel that data transfer speed will be very slow. Imagine each download goes thru a series of proxies. The max transfer speed is limited to the slowest proxy in the link, which could be on a 56k modem! And you can't decide who will be your proxies, as that will negatively affect anonymity.


Also, the slowest proxy may serve a number of concurrent downloads. So it is likely that you will only get a fraction of the slowest bandwidth of the proxies.


Users dissatisfaction comes from:
1. Bandwidth constantly hogged even without downloading
2. Slow downloads (as mentioned above).


Sooner or later, users will realise that it is not cheap even to download illegal content on an anonymized network!

choonkeng
2004-03-01 23:28:52
A simple analysis MUTE scalability & usability
Let n be the total number of nodes in MUTE. At a time, there are p percentage of nodes downloading files from other nodes. It is reasonable to assume that p will not fluctuates too much over time if the network is sufficiently large.


Let r be the number of relay nodes for each download traffic. In practice, to make MUTE scale (with some drawback), we assume that you can't search for & download files futher than r hops away (like in Gnutella). r is usually bounded by TTL, so it is a constant.


Therefore, the number of data transfers (download + relay) handled by each node, is t = p(r+1).


==========
Conclusion
==========


1. When MUTE network is large enough and stable, the number of data transfer handled by each node is a constant, t = p(r + 1), regardless of the total number of nodes in the network. So the traffic (workload) a node handles scales with network size.


2. Every node has different bandwidth capacity, let the bandwidth for node x denoted as b(x). The bandwidth allocated to each data transfer is b(x)/t. However, since data transfers are relayed through a number of relay nodes, the effective bandwidth for each data transfer is the mininum b(x)/t of each relaying node. This makes downloading speed unacceptable for users if nodes' bandwidth are heterogeneous (eg. you're on broadband but one of the relay nodes is on modem).

jimothy
2004-03-16 12:29:42
Another way
I'm replying to an old blog, so this will probably never be read. Regardless...


What I proposed (stop stealing music) is completely practical. The blog is about how to avoid getting caught. It's not about how to compensate artists, or how to solve the piracy epidemic. It's about how you personally can avoid getting caught and punished. And a nearly foolproof way to avoid avoid getting caught and punished for committing a crime is not to commit a crime.