I am not sure that we could safely allow a get file closest to this key command... it might allow some kinds of probing/mapping that might lead to attacks we would want to avoid. On the other hand, it is an interesting idea.
On Sat, May 03, 2003 at 12:11:10PM -0400, Edward J. Huff wrote: > 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 _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
