We seem to be talking past each other, so here is my last response.
No, when I talk about file signatures I am *not* talking about cryptographic signatures. A URI is any old rubbish being an arbitrary tag applied to the file *not* content dependent. I guess you are soewhat confused here, but so are many people.
You are confused. Please see detailed information on URI's, URL's and secure digests.
So you may understand now that proving that someone has downloadable files is totally insufficient.
Thats not the point, and I understand why you would like it to be (convenient loophole - hey, I put it online, but nobody downloaded it!)
The fact is, when the RIAA downloads that file from you, and the hash indicates its a known contraband file, you are screwed, and you have completed at least one illegal distribution of the file.
Lastly, what is with this word contraband. I was trying to be consist with my description. I'll simply call them copyrighted files illegally distributed.
The problem comes down whether a user has copied something iwithout the permission of the original owner.
Yes, and the RIAA is using secure digital hash digests to confirm that the file downloaded is one they own a copyright for, and is not legally allowed for electronic distribution over peer networks by individuals.
The use of a file signature is to provide a comparison to prove that digital duplication ocurred as opposed to two people ripping their own MP3s of a track, i.e., through media shifting.
Yes, and that is a limitation of their method. You would need a unique digital hash for every encoding, as they would all contain different binary data.
The problem is that many networks allow multiple download sources.
This has nothing to do with the current discussion. Neither gnutella or kazaa force multisource downloading, and the RIAA are not using multisource downloading when targeting individuals.
The investigation company working for the RIAA must not only prove that the download could have come from a source, they must prove that the file actually came from that source.
They do. They download the while file from the user, and compare a secure MD5 digest. I cannot make this any clearer.
We know that the chain is already broken, otherwise how could a 66 year old lady be accused of sharing via Kazaa. On her Mac. Somebody is legally incompetent
This is a different issue. This is the inability of the ISP to keep track of customer to IP/date not in the method used to track that an illegally distributed file came from a specific IP.
We are talking about file signatures here not crytographic signatures. A file signature is simply a way of identifying a file by its contents. Some networks actually calculate an MD5 checsum of a file and allow searching by the MD5 checksum (128 bits).
What you call a "file signature" is a cryptographic one way hash digest of the contents. I am not confusing this with digital signatures (which you appeared to be talking about in your first post). Those are something completely different.
A better and more standard name for what you call a "file signature" is the URI - Universal Resource Identifier. One way secure cryptographic hash digests make great URI's.
A cryptographic signature provides non-repudiation which means that nobody but the source of transactionis likely to have originated it. An identifier is just a tag and may have no link with the content. Please do not confuse the semantics.
I'm not going to get pedantic, but you missed the point of my previous post. I know how digital signatures and cryptographic digests work.
What is interesting here is that sharing is very difficult to prosecute. Can I prosecute a man who leaves a CD of my music in the street? What the RIAA is attempting to prove is that the person distributing the music has the same copy as someone else, so it implies that one of the sources copied the other's music.
What? It is not hard to prosecute at all. They download a song from a potential infringer. Instead of having a human listen to it and say "yes, this is an illegal copy" they compare a secure hash of the content and say "yes, this is identical to known contraband". It's actually pretty straightforward and simple to automate.
Many networks allow downloads from multiple sources. Who gets prosecuted then?
In all of the current cases, they downloaded the entire file from the infringer, and confirmed that it was contraband. Your question is interesting, but not relevant to the current legal actions.
I imagine that when they start targeting the multi-source download networks, they will simply not use the multisource downloading and retrieve the whole file from the single source, and continue as they currently do.
Just because multi-source is supported doesn't mean that it is required.
Does KaZaA or Gnutella find the actual IP address the user is at, or simply the proxy IP they may be using? What happens if they subpoena a proxy IP?
This is a good point. Right now the RIAA is only targeting US file sharers, and they do this by tracking the IP of the user they download the content from. If US filesharers used proxies in other countries, they would perform an end run around any potential RIAA threat.
The only problem is that proxies at least double the latency and bandwidth use for a given file transer or query. This usually means that you either cut the download rate significantly, or use high bandwidth dedicated proxies to handle this increased traffic.
Some of the newer file sharing networks, like the one out of the Palestinian refuge camp (dont remember the name) do use proxies in foreign countries in addition to other cryptographic techniques to keep communication private.
the MD5 checksum isn't considered to be kosher as an electronic signature. It may be faked.
Checksums are not really signatures, which use public key encryption (asymmetric ciphers). To defeat a secure one way hash function, you need to find a collision. While it may be possible to find data that produces an identical hash as a copyrighted song, the changes are rediculously small. about 1 in 2^64 IIRC. People have been moving towards SHA-1 and other stronger hashes, but this really isnt something to worry about.
on networks that allow search by signature - the searcher provides a signature so it is easy to fake a hit.
Its not really a signature, its more of a Universal Resource Identifier (URI) or GUID for a given piece of content. Digital signatures rely on public key cryptography.
Lastly, are they really downloading?
Yes, and that was the point I was trying to make. They are really downloading, and comparing the MD5 checksum of the downloaded file against a database of known contraband.
I think they have realized this is the only way they can truly defend their techniques in court; to have a log that says "we downloaded X from person Y at date and time Z".
First, as some have mentioned previously, all of the RIAA legal actions required that the ISP's map date + IP correctly to the right user. This has shown to be problematic, as a number of Mac users have been caught up in the lawsuits.
The RIAA cannot expect the ISP's to provide 100% infallable information. This alone is a bigger threat than the attacks mentioned.
For the duration of these items im going to assume that the networks in question are either FastTrack/KaZaa or Gnutella. These appear to be the networks currently targeted by the RIAA.
Scenario 1: Modifying Search Requests and Search Results in Transit
This is a non starter, as the RIAA have mentioned before regarding their tactics that they rely on MD5 check sums of files that are downloaded from the peer. Simply modifying search results or requests will not incriminate anyone given the method the RIAA is using.
Scenario 2: Spoofing the Originator of Search Results and Search Requests
This falls into the same problem as #1. This will not get someone targeted by the RIAA.
Scenario 3: Renaming a Contraband File to Match Incoming Search Requests
This is a bit more troubling, as the MD5 sums would match the contraband, however, the title may be something completely innocuous - "Slashot Comment Archive" for example.
I find it unlikely that the RIAA would target someone based on MD5's alone. Their tactics appear to use a search to identify potential infringing uploaders, and then a download to confirm contraband via MD5 sum.
If this is the case, then the search for contraband would likely miss this type of file, as it would be renamed to something else (also popular) but unrelated to contraband content.
This does remain a viable risk and potentially exploitable entrapment attack
Scenario 4: Impersonating Another GP2P User
This is another non starter in the same lines as #1 and #2. The RIAA is not using randomly selected user GUID's to identify infringers.
Scenario 5: Tricking an Innocent User Into Downloading Contraband from an Authority
This is a very implausible attack. The RIAA is using custom software to track the network, and does not appear to be uploading the files they are downloading for evidence, as would normally be the case with a standard kazaa/morpheous client.
The chances of downloading a contraband file from the RIAA crawlers seems nil, regardless of how spoofed search resulsts could direct them in this fashion.
In short, there is a potential for abuse, but the methods used by the RIAA prevent a number of these from working effectively. They search keywords and titles, and then confirm contraband with MD5 checksums of the uploaded content.
This is very hard to spoof without actually deploying the contraband on a peer with malicious intent. You are still liable if someone puts contraband on your client!
The biggest danger is still the ISP's inability to properly account for times and dates for each user associated to each IP address. This will continue to target innocent individuals, although the RIAA does appear to drop cases that are blatantly without merit.
True, and I suppose in some point this is splitting hairs. If someone has root, you are screwed. The details I was trying to get at are centered more around non root user applications.
The reasons I cited are a bit broad and overstated. The devil is in the details, and the rational for no library has a lot more to do with increased vulnerabilities in larger systems sharing an address space and using network communication, etc.
My understanding of the situation is that the GNU GPG developers felt that the use of GPG is primarily designed around a user doing specific things with specific data, and that the command line mode suited this type use, and protected (somewhat) against sloppy integration into large potentially insecure applications.
Performance of the exec method obviously sucks in high usage scenarios, but this is not the problem GPG is aimed to solve. If you need a high performance library for serious bulk crypto work, there are a vast majority of libraries out there that provide public and private key ciphers, representation and marshalling wrappers, bindings to sockets and files. Pretty much whatever you want.
If you are interfacing with GPG you are potentially accessing your secure keyring, private keys, etc. You trust the GNU binary, which has been under development and scrutiny for a while, to access these files. You trust in the way it allocates memory and prepares the entropy pool. Etc.
Would you place the same amount of trust in a network app with a GUI and other linked libraries? Would you trust this app to use the interface properly, and not circumvent robust features in exchange for speed? I.e. calling some lower level methods directly and passing in entropy from a rand() source, so that its faster? While you are correct that a compromised system is compromised, regardless of linking or executing a command line, the details are different and significant (to me at least).
Command line invocation separates the GPG app from the invoker by limiting the communication to ARGV, ENV. This is a much more limited interface than the full range of address space sharing of both heap, text segment and symbols that shared library linking implies.
GPG and the small set of libraries it uses can be configured for watch under tripwire and other such systems. It is very hard to circumvent in this situation. A network app with lots of libs can be compromised on the fly, perhaps an exploit in a rendering engine of a page download over the net. Who knows. This would affect the application, but leave gpg intact (communication to and from the child process could be subverted, but there would be some visibility to this that would not be present otherwise)
There are convincing arguments against everything I have just stated, and indeed, perhaps it would be worthwhile to have a library with the caveat prominently displayed that security is only as strong as the weakest link in your application, and for a large, GUI, networked app, there could be many, many links.
You could argue for a library that would invalidate every point I have just made, and I would probably agree. But I see where the GPG developers are coming from, and their rational and resistance against a shared lib (when the C libs that wrap the command line work well) seems reasonable.
Be a LIBRARY, not a stand-alone executable, so it can be linked into anything at all.
If you read about GPG you would realize that the intentional lack of a library is a feature, not a bug. The GPG application relies on some cool extensions to protect memory areas used for the random pool (entropy source) the key generation algorithms, etc.
The moment you pull that out into a simple library you open up a number of attacks. Perhaps the application using the library got 0wn3d by an LD_PRELOAD trick. Perhaps it is allocating memory poorly and it gets swapped to disk, where another rogue process picks it up. Perhaps another rogue library is scanning application memory space and writing keys to a socket over the network. etc, etc.
There are a number of good reasons why there is no library (the current C libs are simply wrappers around exec to the gpg executable - they work fine, use them). Do you want convenience or real security?
The FCC doesn't seem to care much about power levels and antennas in the ISM band. Remember, it's kind of a throwback "freebie" given to appease the anarchist crypto parasites and cheap low end consumer equipment for those unable to afford the "protected and scarce" high dollar bands that go up for auction.:-)
The only exception might be certain commercial product vendors who try and sell out of spec equipment to the masses. That is actually worth their time, but some guy with a primestar dish? no way. [ Like linksys getting pressured to take their 2.4Ghz amps off the market because they could interoperate with too many other "unapproved" equipment configurations. Supposedly they can sell them again after making them harder to use with anything but linksys/cisco. arg. ]
There are a number of smaller WISP's that I've come across in the northwest that run 1/2W and 1W amps on their directional point-to-point and point-to-multipoint configurations, but until someone complains that they are interfering, there is no way the FCC is going to proactively come out and bitch.
Wireless users groups across the nation post plans and site configurations using all sorts of unapproved antennas, radios, amplifiers, etc. There is no widespread FCC CRACKDOWN going on. In fact, I challenge anyone to name an incident where a WiFi user (not company) was pressured or forced by the FCC to alter their equipment back into spec. It doesn't happen.
Personally I think this is a good thing. The FCC has done more harm in the 802.11 space than good. Like antenna connectors. Do you know why there is a proliferation of SMA, RP-SMA, N-type, BNC, RP-BNC, MMCX, and any number of other bastardized formats for antennas and equipment? The FCC requires vendors to make their radio's use proprietary connectors to prevent people from easily and usefully extending the range of their equipment with generic antennas. Not that the vendors mind. Nothing like vendor only parts with the associated 400% markup to pad the profit line.
Let the FCC play with the Big Co's and handle licensed spectrum. The ISM bands are where its at.
We can easily cut our spending by 3/4 without any fear that we will surrender our technological edge.
Agreed. I would love to see this cut back. I should have been clearer that this was in response to "any investment" at all, not necessarily the amount of that investment.
Throughout America's adventure in free government, our basic purposes have been to keep the peace; to foster progress in human achievement, and to enhance liberty, dignity and integrity among people and among nations. To strive for less would be unworthy of a free and religious people. Any failure traceable to arrogance, or our lack of comprehension or readiness to sacrifice would inflict upon us grievous hurt both at home and abroad....
In the councils of government, we must guard against the acquisition of unwarranted influence, whether sought or unsought, by the militaryindustrial complex. The potential for the disastrous rise of misplaced power exists and will persist.
We must never let the weight of this combination endanger our liberties or democratic processes. We should take nothing for granted. Only an alert and knowledgeable citizenry can compel the proper meshing of the huge industrial and military machinery of defense with our peaceful methods and goals, so that security and liberty may prosper together.
I bet he is rolling in his grave... [ emphasis mine ]
Now if only we could get funding for research into accountability, responsibility, and integrity in government and political organizations.
Sadly, I doubt that would get funded. The biggest concern I have today is not weapons, but the decision makers insulated from the deceitful and irresponsible use of these weapons.
Bush and Co. have coerced the US into a war against Iraq and terrorism in general under false pretense, for political and monetary gain, without any repercussion.
The US is about to spend a record $87 billion, on top of $80 billion already approved for the Iraq war. Add into that the $20 billion spent on Afgh. and you have a nice $187 BILLION DOLLAR price tag.
The size of that figure is just disturbing, esp. considered in light of the current job-loss recovery, the sad state of education and health care, and other pressing domestic needs.
This whole thread seems to express a kind of "if we had no weapons there would be world peace" mentality.
Think about this for a moment. If we eliminated weapons research could we expect other countries to do the same, and if not, for them to leave us alone? I don't think so.
If we greatly reduced weapons research such that it was only performed in time of war, could we assume this would be adequate protection against those we are fighting? I don't think so.
I'm sure there are a million reasons why scientists work on weapons systems, but I don't think many of them have this crisis of conscience as presented.
If we had been slower in development of nuclear weapons, or long range bombers, or other such instruments during and shortly after the great wars, would we (USA/EU) still be here to contemplate the evil of military technology? Who is to say some facist regime without scruples would not have walked all over democracies far and wide two decades ago?
I detest weapons and instruments of death, but I also accept the fact that the world is a harsh mistress; far too often people and nations find themselves in a kill or be killed situation.
I'm not going to work on weapons systems, but I am glad that some very smart people are working on them, and employing the technology to protect my country.
Actually CSMA/CA does not include handling of hidden nodes. RTS/CTS was specifically ADDED to 802.11, AFTER CSMA/CA was decided, to handle the hidden node problem
Ok, if you want to be pedantic, I was talking about CSMA/CA in the context of the 802.11 standard, which uses RTS/CTS to address the problem, just like you said. There, that's better.
Score another point for Wi-FUD. That is ONE solution but not the ONLY solution. You could of course, also reduce contention for the shared medium by installing multiple hub radios with sector antennas and save a lot of money.... until a given sector gets overloaded. then you are back at square 1. Phased arrays are much more resilient as their beams are much, much more directed.
Adding more radios and sector antennas is simply another band-aid IMHO. Sure, it works, but so does the traffic shaping/psuedo token ring method.
OR, you could upgrade to a faster wireless standard like a or g, and eliminate the contention altogether!
Yeah, because 802.11g and 802.11a use a completely differnt MAC right? wrong. they have the same problem. its just less pronounced because you have more bandwidth. 802.11g is the worst of these two, as you get the same problems as 802.11b, at 802.11b speeds, with just a single 802.11b client on the 802.11g network (hopefully vendors are fixing this problem, but its inherent to the backwards compatible nature of g itself. They have mitigated this problem a bit with prioritization, but it is still very much a problem)
BUT, the solution is to INCREASE available bandwidth, which leads to new possibilities and innovations and solves the old medium access contention problem at the same time.
Sorry, the 802.11 MAC is a pile of crap full of inefficiencies in the name of simplicity and cheap implementation. Things like full duplex, smarter rate management, better CA mechanisms, all have vastly more potential for increasing throughput than simply jacking up existing bit rates with the 802.11 MAC.
Sorry, to me this is still just a variant of traffic shaping. Push the tokens down below IP in the stack, with firmware support, and you have a token ring system.
You may also want to try forcing the communication rates for clients operating under contention.
iwconfig eth0 rate 11M
This bypasses the brain dead default behavior where clients drop rates during contention. If you know you have good SQ, set it high.
Last, any kind of ingress traffic from the clients is completely outside the control of the queues (it's already passed over the wireless medium) which is why I dislike this approach compared to something at a lower level.
Here's to hoping the GNU Radio for 2.4Ghz and/or reverse engineered drivers for software defined radios (Broadcom/Atheros?) are available soon for the kind of layer2 tweaks that you hint at.
the 802.11 MAC really does suck shit through a straw. Hopefully we wont have to live with it much longer...
This is not really a hidden node problem, as they make it out to be.
This is more a problem with the inherent lack of scalability of a CSMA/CA architecture. Everyone is familiar with the way ethernet degrades under saturation: you only get about 70% of that 100Mbit throughput utilized. Ethernet is CSMA/CD - collision detection.
In wireless the problem is even more pronounced in infrastructure mode because you are using CSMA/CA -- collision avoidance. This means that for every packet to be sent, the clients must coordinate use of the medium before sending, using a RTS/CTS handshake.
(client) can I send now? (AP) not your turn yet (client) can I send now? (AP) not your turn yet (client) can I send now? (AP) yes (client)... data packet...
When you put many clients (20+) on the same AP sharing the same medium, a large amount of bandwidth is spent simply coordinating contention free access to the wireless medium itself.
Traffic shaping (which is all frottle is doing) helps ease this problem by reducing the amount of data clients try to send/recv in a given period of time, and thus reduces some of the contention.
This is simply a band-aid on a more fundamental problem, however.
The only true way to prevent this kind of inefficiency for larger numbers of clients is to use a true wireless phased array switch, like vivato, which can effectively emulate a dedicated medium to each client, preventing any contention that arises in the broadcast CSMA/CA situation.
Also, it is important to note that communication between nodes on the wireless will NOT be shaped by the frottle queues unless you are using hostap or some other linux based access point. In such a scenario, two nodes talking to each other could use as much of the medium as they liked (as coordinated by the access point itself) without frottle seeing any of the traffic.
"By cross correlating the received signal with the (known) barker sequence at all three base stations"
Try doing that within the tolerances required to measure distance based on the propagation of radio waves.
The only systems that can do triangulation worth a shit are phased array / smart antenna technology, which can determine direction without using a moving highly directional antenna.
The problem with measuring some companies is that their access points come with unique default SSIDs. One is Proxim Orinoco.
Quite right. There are also some, like Buffalo, which use the MAC ID as the default ssid. This is a really bad measure of popularity, but even still, I was surprisec how close the results meshed. (I.e. linksys is only off a few percent)
In 2002, Linksys overtook Cisco Systems as the leading wireless equipment vendor, accounting for 14.1 percent of revenue. Cisco slipped to the No. 2 position with a 13.9 percent market share.
Buffalo Technology was the No. 3 vendor in market share, followed in order by D-Link and Proxim.
In war driving about 14,000 access points in the northwest the results are fairly consistent with the numbers the article mentions:
Please take note of the following system requirements for Haystack:
* Pentium III 700mhz-based computer or better (Pentium 4 2ghz strongly recommended)
* 512 megabytes of RAM (768 megabytes strongly recommended)
* Windows 2000, Windows XP, or Linux (Linux build requires GTK+ 2.0 libraries)
* At least 1 gigabyte of disk space (or more, as your repository grows)
* Java 2 Development Kit (JDK) 1.4 or later note that JDK 1.4.1 does not work with Haystack; use JDK 1.4.1_02 instead)
Even though people can still war drive (or even war fly) and find your access points, even if they managed to crack the WEP keys and associate to the AP, the network will still be secure because of the multiple layers that have been put in place.
Actually, layer2 is completely unauthenticated, so anyone can associate with your access point using no key or the wrong key. IP and above will get dropped however.
The lack of an authentication mechanism in the 802.11b MAC leaves a number of nasty weaknesses that can be exploited by malicious persons.
Denial of service (forged disassociation) and active man-in-the-middle attacks (using higher signal and forged BSSID/SSID) continue to remain possible in even the latest security extensions to 802.11.
I'm surprised no mention was made of IDS systems that can detect and respond in real time to 802.11 layer 2 attacks (and other higher level IDS checks on the IP traffic), although even these are of limited utility...
I'm a bit surprised that no p2p project has tried to do UDP connection splicing to allow two peers, both behind internet connection sharing (NAT) to talk to each other.
Check out the UDP based messaging protocol used in the alpine search communication. It supports dual NAT communication between peers and reliable/unreliable transport of datagram packets.
For bulk transport (most apps use UDP for messaging only) you would need to use something like AirHook to handle retransmission and high throughput transfer.
For those attending codecon there will also be a WiFi Caravan traveling from Portland OR to San Francisco which all are welcome to participate in.
We will be out and about on the evenings after the conference precedings if you dont feel like driving all the way to portland:-)
As one last FYI, be sure to bring your wireless gear to codecon! There will be lots of A/V streaming going on, and lots of wireless enabled presentations in addition to other fun stuff.
Slashdot Mirror
We seem to be talking past each other, so here is my last response.
No, when I talk about file signatures I am *not* talking about cryptographic signatures. A URI is any old rubbish being an arbitrary tag applied to the file *not* content dependent. I guess you are soewhat confused here, but so are many people.
You are confused. Please see detailed information on URI's, URL's and secure digests.
So you may understand now that proving that someone has downloadable files is totally insufficient.
Thats not the point, and I understand why you would like it to be (convenient loophole - hey, I put it online, but nobody downloaded it!)
The fact is, when the RIAA downloads that file from you, and the hash indicates its a known contraband file, you are screwed, and you have completed at least one illegal distribution of the file.
Lastly, what is with this word contraband. I was trying to be consist with my description. I'll simply call them copyrighted files illegally distributed.
The problem comes down whether a user has copied something iwithout the permission of the original owner.
Yes, and the RIAA is using secure digital hash digests to confirm that the file downloaded is one they own a copyright for, and is not legally allowed for electronic distribution over peer networks by individuals.
The use of a file signature is to provide a comparison to prove that digital duplication ocurred as opposed to two people ripping their own MP3s of a track, i.e., through media shifting.
Yes, and that is a limitation of their method. You would need a unique digital hash for every encoding, as they would all contain different binary data.
The problem is that many networks allow multiple download sources.
This has nothing to do with the current discussion. Neither gnutella or kazaa force multisource downloading, and the RIAA are not using multisource downloading when targeting individuals.
The investigation company working for the RIAA must not only prove that the download could have come from a source, they must prove that the file actually came from that source.
They do. They download the while file from the user, and compare a secure MD5 digest. I cannot make this any clearer.
We know that the chain is already broken, otherwise how could a 66 year old lady be accused of sharing via Kazaa. On her Mac. Somebody is legally incompetent
This is a different issue. This is the inability of the ISP to keep track of customer to IP/date not in the method used to track that an illegally distributed file came from a specific IP.
We are talking about file signatures here not crytographic signatures. A file signature is simply a way of identifying a file by its contents. Some networks actually calculate an MD5 checsum of a file and allow searching by the MD5 checksum (128 bits).
What you call a "file signature" is a cryptographic one way hash digest of the contents. I am not confusing this with digital signatures (which you appeared to be talking about in your first post). Those are something completely different.
A better and more standard name for what you call a "file signature" is the URI - Universal Resource Identifier. One way secure cryptographic hash digests make great URI's.
A cryptographic signature provides non-repudiation which means that nobody but the source of transactionis likely to have originated it. An identifier is just a tag and may have no link with the content. Please do not confuse the semantics.
I'm not going to get pedantic, but you missed the point of my previous post. I know how digital signatures and cryptographic digests work.
What is interesting here is that sharing is very difficult to prosecute. Can I prosecute a man who leaves a CD of my music in the street? What the RIAA is attempting to prove is that the person distributing the music has the same copy as someone else, so it implies that one of the sources copied the other's music.
What? It is not hard to prosecute at all. They download a song from a potential infringer. Instead of having a human listen to it and say "yes, this is an illegal copy" they compare a secure hash of the content and say "yes, this is identical to known contraband". It's actually pretty straightforward and simple to automate.
Many networks allow downloads from multiple sources. Who gets prosecuted then?
In all of the current cases, they downloaded the entire file from the infringer, and confirmed that it was contraband. Your question is interesting, but not relevant to the current legal actions.
I imagine that when they start targeting the multi-source download networks, they will simply not use the multisource downloading and retrieve the whole file from the single source, and continue as they currently do.
Just because multi-source is supported doesn't mean that it is required.
Does KaZaA or Gnutella find the actual IP address the user is at, or simply the proxy IP they may be using? What happens if they subpoena a proxy IP?
This is a good point. Right now the RIAA is only targeting US file sharers, and they do this by tracking the IP of the user they download the content from. If US filesharers used proxies in other countries, they would perform an end run around any potential RIAA threat.
The only problem is that proxies at least double the latency and bandwidth use for a given file transer or query. This usually means that you either cut the download rate significantly, or use high bandwidth dedicated proxies to handle this increased traffic.
Some of the newer file sharing networks, like the one out of the Palestinian refuge camp (dont remember the name) do use proxies in foreign countries in addition to other cryptographic techniques to keep communication private.
the MD5 checksum isn't considered to be kosher as an electronic signature. It may be faked.
Checksums are not really signatures, which use public key encryption (asymmetric ciphers). To defeat a secure one way hash function, you need to find a collision. While it may be possible to find data that produces an identical hash as a copyrighted song, the changes are rediculously small. about 1 in 2^64 IIRC. People have been moving towards SHA-1 and other stronger hashes, but this really isnt something to worry about.
on networks that allow search by signature - the searcher provides a signature so it is easy to fake a hit.
Its not really a signature, its more of a Universal Resource Identifier (URI) or GUID for a given piece of content. Digital signatures rely on public key cryptography.
Lastly, are they really downloading?
Yes, and that was the point I was trying to make. They are really downloading, and comparing the MD5 checksum of the downloaded file against a database of known contraband.
I think they have realized this is the only way they can truly defend their techniques in court; to have a log that says "we downloaded X from person Y at date and time Z".
First, as some have mentioned previously, all of the RIAA legal actions required that the ISP's map date + IP correctly to the right user. This has shown to be problematic, as a number of Mac users have been caught up in the lawsuits.
The RIAA cannot expect the ISP's to provide 100% infallable information. This alone is a bigger threat than the attacks mentioned.
On to the paper. You can find it via google.
For the duration of these items im going to assume that the networks in question are either FastTrack/KaZaa or Gnutella. These appear to be the networks currently targeted by the RIAA.
Scenario 1: Modifying Search Requests and Search Results in Transit
This is a non starter, as the RIAA have mentioned before regarding their tactics that they rely on MD5 check sums of files that are downloaded from the peer. Simply modifying search results or requests will not incriminate anyone given the method the RIAA is using.
Scenario 2: Spoofing the Originator of Search Results and Search Requests
This falls into the same problem as #1. This will not get someone targeted by the RIAA.
Scenario 3: Renaming a Contraband File to Match Incoming Search Requests
This is a bit more troubling, as the MD5 sums would match the contraband, however, the title may be something completely innocuous - "Slashot Comment Archive" for example.
I find it unlikely that the RIAA would target someone based on MD5's alone. Their tactics appear to use a search to identify potential infringing uploaders, and then a download to confirm contraband via MD5 sum.
If this is the case, then the search for contraband would likely miss this type of file, as it would be renamed to something else (also popular) but unrelated to contraband content.
This does remain a viable risk and potentially exploitable entrapment attack
Scenario 4: Impersonating Another GP2P User
This is another non starter in the same lines as #1 and #2. The RIAA is not using randomly selected user GUID's to identify infringers.
Scenario 5: Tricking an Innocent User Into Downloading Contraband from an Authority
This is a very implausible attack. The RIAA is using custom software to track the network, and does not appear to be uploading the files they are downloading for evidence, as would normally be the case with a standard kazaa/morpheous client.
The chances of downloading a contraband file from the RIAA crawlers seems nil, regardless of how spoofed search resulsts could direct them in this fashion.
In short, there is a potential for abuse, but the methods used by the RIAA prevent a number of these from working effectively. They search keywords and titles, and then confirm contraband with MD5 checksums of the uploaded content.
This is very hard to spoof without actually deploying the contraband on a peer with malicious intent. You are still liable if someone puts contraband on your client!
The biggest danger is still the ISP's inability to properly account for times and dates for each user associated to each IP address. This will continue to target innocent individuals, although the RIAA does appear to drop cases that are blatantly without merit.
True, and I suppose in some point this is splitting hairs. If someone has root, you are screwed. The details I was trying to get at are centered more around non root user applications.
The reasons I cited are a bit broad and overstated. The devil is in the details, and the rational for no library has a lot more to do with increased vulnerabilities in larger systems sharing an address space and using network communication, etc.
My understanding of the situation is that the GNU GPG developers felt that the use of GPG is primarily designed around a user doing specific things with specific data, and that the command line mode suited this type use, and protected (somewhat) against sloppy integration into large potentially insecure applications.
Performance of the exec method obviously sucks in high usage scenarios, but this is not the problem GPG is aimed to solve. If you need a high performance library for serious bulk crypto work, there are a vast majority of libraries out there that provide public and private key ciphers, representation and marshalling wrappers, bindings to sockets and files. Pretty much whatever you want.
If you are interfacing with GPG you are potentially accessing your secure keyring, private keys, etc. You trust the GNU binary, which has been under development and scrutiny for a while, to access these files. You trust in the way it allocates memory and prepares the entropy pool. Etc.
Would you place the same amount of trust in a network app with a GUI and other linked libraries? Would you trust this app to use the interface properly, and not circumvent robust features in exchange for speed? I.e. calling some lower level methods directly and passing in entropy from a rand() source, so that its faster? While you are correct that a compromised system is compromised, regardless of linking or executing a command line, the details are different and significant (to me at least).
Command line invocation separates the GPG app from the invoker by limiting the communication to ARGV, ENV. This is a much more limited interface than the full range of address space sharing of both heap, text segment and symbols that shared library linking implies.
GPG and the small set of libraries it uses can be configured for watch under tripwire and other such systems. It is very hard to circumvent in this situation. A network app with lots of libs can be compromised on the fly, perhaps an exploit in a rendering engine of a page download over the net. Who knows. This would affect the application, but leave gpg intact (communication to and from the child process could be subverted, but there would be some visibility to this that would not be present otherwise)
There are convincing arguments against everything I have just stated, and indeed, perhaps it would be worthwhile to have a library with the caveat prominently displayed that security is only as strong as the weakest link in your application, and for a large, GUI, networked app, there could be many, many links.
You could argue for a library that would invalidate every point I have just made, and I would probably agree. But I see where the GPG developers are coming from, and their rational and resistance against a shared lib (when the C libs that wrap the command line work well) seems reasonable.
I may change my mind next week...
Be a LIBRARY, not a stand-alone executable, so it can be linked into anything at all.
If you read about GPG you would realize that the intentional lack of a library is a feature, not a bug. The GPG application relies on some cool extensions to protect memory areas used for the random pool (entropy source) the key generation algorithms, etc.
The moment you pull that out into a simple library you open up a number of attacks. Perhaps the application using the library got 0wn3d by an LD_PRELOAD trick. Perhaps it is allocating memory poorly and it gets swapped to disk, where another rogue process picks it up. Perhaps another rogue library is scanning application memory space and writing keys to a socket over the network. etc, etc.
There are a number of good reasons why there is no library (the current C libs are simply wrappers around exec to the gpg executable - they work fine, use them). Do you want convenience or real security?
The FCC doesn't seem to care much about power levels and antennas in the ISM band. Remember, it's kind of a throwback "freebie" given to appease the anarchist crypto parasites and cheap low end consumer equipment for those unable to afford the "protected and scarce" high dollar bands that go up for auction. :-)
The only exception might be certain commercial product vendors who try and sell out of spec equipment to the masses. That is actually worth their time, but some guy with a primestar dish? no way. [ Like linksys getting pressured to take their 2.4Ghz amps off the market because they could interoperate with too many other "unapproved" equipment configurations. Supposedly they can sell them again after making them harder to use with anything but linksys/cisco. arg. ]
There are a number of smaller WISP's that I've come across in the northwest that run 1/2W and 1W amps on their directional point-to-point and point-to-multipoint configurations, but until someone complains that they are interfering, there is no way the FCC is going to proactively come out and bitch.
Wireless users groups across the nation post plans and site configurations using all sorts of unapproved antennas, radios, amplifiers, etc. There is no widespread FCC CRACKDOWN going on. In fact, I challenge anyone to name an incident where a WiFi user (not company) was pressured or forced by the FCC to alter their equipment back into spec. It doesn't happen.
Personally I think this is a good thing. The FCC has done more harm in the 802.11 space than good. Like antenna connectors. Do you know why there is a proliferation of SMA, RP-SMA, N-type, BNC, RP-BNC, MMCX, and any number of other bastardized formats for antennas and equipment? The FCC requires vendors to make their radio's use proprietary connectors to prevent people from easily and usefully extending the range of their equipment with generic antennas. Not that the vendors mind. Nothing like vendor only parts with the associated 400% markup to pad the profit line.
Let the FCC play with the Big Co's and handle licensed spectrum. The ISM bands are where its at.
No kidding. Ray went through pains to explain that this is all software shipped 18 months prior to the patent filing!
That is the very definition of prior art, that it occured priot to the application or implementation of the ideas in question.
Sheesh. Read his post...
We can easily cut our spending by 3/4 without any fear that we will surrender our technological edge.
Agreed. I would love to see this cut back. I should have been clearer that this was in response to "any investment" at all, not necessarily the amount of that investment.
Throughout America's adventure in free government, our basic purposes have been to keep the peace; to foster progress in human achievement, and to enhance liberty, dignity and integrity among people and among nations. To strive for less would be unworthy of a free and religious people. Any failure traceable to arrogance, or our lack of comprehension or readiness to sacrifice would inflict upon us grievous hurt both at home and abroad. ...
In the councils of government, we must guard against the acquisition of unwarranted influence, whether sought or unsought, by the militaryindustrial complex. The potential for the disastrous rise of misplaced power exists and will persist.
We must never let the weight of this combination endanger our liberties or democratic processes. We should take nothing for granted. Only an alert and knowledgeable citizenry can compel the proper meshing of the huge industrial and military machinery of defense with our peaceful methods and goals, so that security and liberty may prosper together.
I bet he is rolling in his grave... [ emphasis mine ]
Now if only we could get funding for research into accountability, responsibility, and integrity in government and political organizations.
Sadly, I doubt that would get funded. The biggest concern I have today is not weapons, but the decision makers insulated from the deceitful and irresponsible use of these weapons.
Bush and Co. have coerced the US into a war against Iraq and terrorism in general under false pretense, for political and monetary gain, without any repercussion.
The US is about to spend a record $87 billion, on top of $80 billion already approved for the Iraq war. Add into that the $20 billion spent on Afgh. and you have a nice $187 BILLION DOLLAR price tag.
The size of that figure is just disturbing, esp. considered in light of the current job-loss recovery, the sad state of education and health care, and other pressing domestic needs.
This whole thread seems to express a kind of "if we had no weapons there would be world peace" mentality.
Think about this for a moment. If we eliminated weapons research could we expect other countries to do the same, and if not, for them to leave us alone? I don't think so.
If we greatly reduced weapons research such that it was only performed in time of war, could we assume this would be adequate protection against those we are fighting? I don't think so.
I'm sure there are a million reasons why scientists work on weapons systems, but I don't think many of them have this crisis of conscience as presented.
If we had been slower in development of nuclear weapons, or long range bombers, or other such instruments during and shortly after the great wars, would we (USA/EU) still be here to contemplate the evil of military technology? Who is to say some facist regime without scruples would not have walked all over democracies far and wide two decades ago?
I detest weapons and instruments of death, but I also accept the fact that the world is a harsh mistress; far too often people and nations find themselves in a kill or be killed situation.
I'm not going to work on weapons systems, but I am glad that some very smart people are working on them, and employing the technology to protect my country.
Actually CSMA/CA does not include handling of hidden nodes. RTS/CTS was specifically ADDED to 802.11, AFTER CSMA/CA was decided, to handle the hidden node problem
... until a given sector gets overloaded. then you are back at square 1. Phased arrays are much more resilient as their beams are much, much more directed.
Ok, if you want to be pedantic, I was talking about CSMA/CA in the context of the 802.11 standard, which uses RTS/CTS to address the problem, just like you said. There, that's better.
Score another point for Wi-FUD. That is ONE solution but not the ONLY solution. You could of course, also reduce contention for the shared medium by installing multiple hub radios with sector antennas and save a lot of money.
Adding more radios and sector antennas is simply another band-aid IMHO. Sure, it works, but so does the traffic shaping/psuedo token ring method.
OR, you could upgrade to a faster wireless standard like a or g, and eliminate the contention altogether!
Yeah, because 802.11g and 802.11a use a completely differnt MAC right? wrong. they have the same problem. its just less pronounced because you have more bandwidth. 802.11g is the worst of these two, as you get the same problems as 802.11b, at 802.11b speeds, with just a single 802.11b client on the 802.11g network (hopefully vendors are fixing this problem, but its inherent to the backwards compatible nature of g itself. They have mitigated this problem a bit with prioritization, but it is still very much a problem)
BUT, the solution is to INCREASE available bandwidth, which leads to new possibilities and innovations and solves the old medium access contention problem at the same time.
Sorry, the 802.11 MAC is a pile of crap full of inefficiencies in the name of simplicity and cheap implementation. Things like full duplex, smarter rate management, better CA mechanisms, all have vastly more potential for increasing throughput than simply jacking up existing bit rates with the 802.11 MAC.
Sorry, to me this is still just a variant of traffic shaping. Push the tokens down below IP in the stack, with firmware support, and you have a token ring system.
...
You may also want to try forcing the communication rates for clients operating under contention.
iwconfig eth0 rate 11M
This bypasses the brain dead default behavior where clients drop rates during contention. If you know you have good SQ, set it high.
Last, any kind of ingress traffic from the clients is completely outside the control of the queues (it's already passed over the wireless medium) which is why I dislike this approach compared to something at a lower level.
Here's to hoping the GNU Radio for 2.4Ghz and/or reverse engineered drivers for software defined radios (Broadcom/Atheros?) are available soon for the kind of layer2 tweaks that you hint at.
the 802.11 MAC really does suck shit through a straw. Hopefully we wont have to live with it much longer
True, I should have added "or an access point in bridge mode".
If you use an AP that does the NAT/router for you, anything between the clients is not going to go through the linux router.
This is not really a hidden node problem, as they make it out to be.
... data packet ...
This is more a problem with the inherent lack of scalability of a CSMA/CA architecture. Everyone is familiar with the way ethernet degrades under saturation: you only get about 70% of that 100Mbit throughput utilized. Ethernet is CSMA/CD - collision detection.
In wireless the problem is even more pronounced in infrastructure mode because you are using CSMA/CA -- collision avoidance. This means that for every packet to be sent, the clients must coordinate use of the medium before sending, using a RTS/CTS handshake.
(client) can I send now?
(AP) not your turn yet
(client) can I send now?
(AP) not your turn yet
(client) can I send now?
(AP) yes
(client)
When you put many clients (20+) on the same AP sharing the same medium, a large amount of bandwidth is spent simply coordinating contention free access to the wireless medium itself.
Traffic shaping (which is all frottle is doing) helps ease this problem by reducing the amount of data clients try to send/recv in a given period of time, and thus reduces some of the contention.
This is simply a band-aid on a more fundamental problem, however.
The only true way to prevent this kind of inefficiency for larger numbers of clients is to use a true wireless phased array switch, like vivato, which can effectively emulate a dedicated medium to each client, preventing any contention that arises in the broadcast CSMA/CA situation.
Also, it is important to note that communication between nodes on the wireless will NOT be shaped by the frottle queues unless you are using hostap or some other linux based access point. In such a scenario, two nodes talking to each other could use as much of the medium as they liked (as coordinated by the access point itself) without frottle seeing any of the traffic.
"By cross correlating the received signal with the (known) barker sequence at all three base stations"
Try doing that within the tolerances required to measure distance based on the propagation of radio waves.
The only systems that can do triangulation worth a shit are phased array / smart antenna technology, which can determine direction without using a moving highly directional antenna.
The problem with measuring some companies is that their access points come with unique default SSIDs. One is Proxim Orinoco.
Quite right. There are also some, like Buffalo, which use the MAC ID as the default ssid. This is a really bad measure of popularity, but even still, I was surprisec how close the results meshed. (I.e. linksys is only off a few percent)
Buffalo Technology was the No. 3 vendor in market share, followed in order by D-Link and Proxim.
In war driving about 14,000 access points in the northwest the results are fairly consistent with the numbers the article mentions:
Popular ESSID's:
1. linksys 2051 (17.4%)
2. default 967 (8.22%)
3. Wireless 526 (4.47%)
4. MSFTWLAN 374 (3.18%)
5. WLAN 176 (1.49%)
6. tsunami 131 (1.11%)
7. IntelWLAN 124 (1.05%)
8. 101 119 (1.01%)
9. tmobile 118 (1.00%)
10. SpeedStream 101 (0.85%)
I'll let you figure out which default SSID is from which vendor
Arg, cut-n-paste errors. Should read 512M
Please take note of the following system requirements for Haystack:
* Pentium III 700mhz-based computer or better (Pentium 4 2ghz strongly recommended)
* 512 megabytes of RAM (768 megabytes strongly recommended)
* Windows 2000, Windows XP, or Linux (Linux build requires GTK+ 2.0 libraries)
* At least 1 gigabyte of disk space (or more, as your repository grows)
* Java 2 Development Kit (JDK) 1.4 or later note that JDK 1.4.1 does not work with Haystack; use JDK 1.4.1_02 instead)
From the system requirements:
- Pentium III 700mhz-based computer or better (Pentium 4 2ghz strongly recommended)
- 12 megabytes of RAM (768 megabytes strongly recommended)
s/strongly recommended/REQUIRED/
Even though people can still war drive (or even war fly) and find your access points, even if they managed to crack the WEP keys and associate to the AP, the network will still be secure because of the multiple layers that have been put in place.
...
Actually, layer2 is completely unauthenticated, so anyone can associate with your access point using no key or the wrong key. IP and above will get dropped however.
The lack of an authentication mechanism in the 802.11b MAC leaves a number of nasty weaknesses that can be exploited by malicious persons.
Denial of service (forged disassociation) and active man-in-the-middle attacks (using higher signal and forged BSSID/SSID) continue to remain possible in even the latest security extensions to 802.11.
I'm surprised no mention was made of IDS systems that can detect and respond in real time to 802.11 layer 2 attacks (and other higher level IDS checks on the IP traffic), although even these are of limited utility
I'm a bit surprised that no p2p project has tried to do UDP connection splicing
to allow two peers, both behind internet connection sharing (NAT) to talk to
each other.
Check out the UDP based messaging protocol used in the alpine search communication. It supports dual NAT communication between peers and reliable/unreliable transport of datagram packets.
For bulk transport (most apps use UDP for messaging only) you would need to use something like AirHook to handle retransmission and high throughput transfer.
For those attending codecon there will also be a WiFi Caravan traveling from Portland OR to San Francisco which all are welcome to participate in.
:-)
We will be out and about on the evenings after the conference precedings if you dont feel like driving all the way to portland
As one last FYI, be sure to bring your wireless gear to codecon! There will be lots of A/V streaming going on, and lots of wireless enabled presentations in addition to other fun stuff.
Check out the InfoAnarchy CodeCon 02 coverage if you would like a better feel for what this conference is all about...