I suppose maybe this belongs on the TECH list, but that list seems to have nothing but spam, while this list doesn't.
Also, this idea addresses the node specialization problem by separating the routing problem from the defense against attack on specific content. The defense problem is moved out of the freenet protocol to the application, removing some constraints and making it easier to solve the routing problem. I would like to propose a different approach to protecting against attack on content. It seems to me that any node in the U.S. can be forced to reject requests for any specific CHK and refuse to cache that CHK, if the copyright owner files a DMCA document demanding that action. If the node operator does not comply, the node gets shut down by the ISP, who wants to stay in business. The argument that requesting the CHK causes it to move to the node fails: all freenet nodes can be regarded as holding all CHK's, and if a copyright owner can find out the CHK of his content, he can insist that all freenet nodes in the U.S. must refuse to deliver that CHK to other nodes, and shut down all of them which fail to comply. But it doesn't have to be that way. Suppose when you want to place content into Freenet, you always pad the content to a standard length, and calculate a whole separate file of random bits of the same length. Also, you fetch a bunch of randomly chosen existing files of that same length, by creating a random Freenet key and sending a (new) protocol request for the file with the closest key encountered in the specified HTL. You choose random symmetric keys and encrypt some of the existing files. Then you XOR the padded content, the file of random bits, and the encrypted existing files. Then encrypt the result, and insert the new random file, the encrypted existing files, and the encrypted result as CHKs. Separately (and later), a formula for calculating the content is circulated among all of the nodes. This formula is tiny compared to the content. It is a different type of freenet key, where the key represents some specific content, and the value is the formula for the content. Instead of requesting these keys, nodes listen for them. This has several advantages: (1) Inserting the encrypted existing files results in redundant storage of that information on different nodes. If it is known which content the files originally contributed to, new formulas for that content can be posted. Anyone attacking the content is always a day behind. (2) It can be hard to say which of the files are new and which derived from existing files, especially if the delay between release of the files and release of the formula for the content is random and long enough for other content to use the newly created files. (3) Using some existing files without change in the formula for new content will tend to cause any given file on Freenet to be referenced in the formulas for many completely independent sets of content. Using re-encrypted files while issuing revised formulas for the existing content which used the files also has this effect: the re-encrypted files are referenced in many independent sets of content. (4) There is now no reason to worry about attacks on particular freenet keys, so routing can be done in the most efficient manner. --- This approach amounts to an almost magical method of compressing arbitrary data into quite small files. It works so long as CHK collisions do not occur. The random data stored under a CHK is essentially compressed to the size of the CHK. The probability of CHK collisions is no doubt a little higher, and maybe the hash would need to be longer. All nodes are continually requesting random CHK's for use in encoding new content or decoding existing content, who is to say which? When the nodes emit new files which are nothing but encrypted versions of existing files, they are preserving existing content by creating a new formula for it, but they also might be inserting new content. When the node happens to know the formula for some content it needs, it fetches the necessary CHK's along with many others, and pulls the content out. No observer can tell when it does this. It also puts the content back into Freenet under a different formula. Because nodes do not request specific content, but only monitor the formula stream for the named content they want, a DMCA attack is not possible. By the time the content owner discovers which CHK's are needed to construct his content, a completely different set of CHK's are in use holding it. He cannot prove that any particular node is refusing to filter out his content, because he cannot request it. Well, nodes will have to accept his requests to filter out certain formula keys. First, the owner has to find out a key which represents a formula for his content. Then he has to fetch the content and verify that the key works. Then he can interdict that key. But by then, there is a different key and a different formula. He can never interdict the actual large datafiles, because they are used for so many other purposes. -- Ed Huff _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
