On Fri, Jul 28, 2000 at 11:01:22AM +0100, Michael ROGERS wrote: > [Freenet developers - if you'd like us to move this discussion off-list, just > say the word] > > I've been thinking about the implementation of a music-sharing client. Here > are some thoughts. > > ---------------------------------------------------------------------------- > > Songs are encrypted with a random RC4 key, then hashed. The hash is used as a > key to insert the file into freenet (CHK). The hash and the RC4 key are > concatenated to form the "read key". You need this to retrieve the file and > decrypt it. The CHK is not enough to decrypt the file, so the nodes storing > and handling the file *cannot* know what they're handling.
Document level encryption is already done. This is unnecessary > > Encrypting the file before hashing it makes it possible to store multiple > copies, so if one is censored you can easily insert another (and it will be > stored on a different node). It also makes it impossible to guess which CHK > the file is stored under, but that's not much of an advantage because you > have to reveal the CHK at some point so the users can download the file. :) Also unnecessary, since the entire point behind Freenet is that it *can't* be censored. You're developing anti-censorship methods for the wrong system. > PROBLEM 1: MULTIPLE ENCODINGS, ONE NAME > > The first problem is that we need to be able to retrieve files by giving > *only* the song title and artist's name. The suggestion of requiring a > version number / encoding number to be provided doesn't work - the user would > have to guess the version number. If there are few enough version numbers per > song to make them guessable, they can all be squatted. If there are enough to > make squatting them all impractical, guessing is also impractical. If the > user has to get the version number by out-of-band means, he might as well > just get the CHK of the file and we can forget about names altogether. This is solved by searching. Just use the keyindexes until searching is complete. > > So to prevent key squatting and allow searching by name, it needs to be > possible to store any number of files and use a single string to retrieve > them. The users can then decide what's a valid encoding and what's noise (or > misnamed). HUGE problem with spam. > > This means we need a directory for each artist+song string, stored under the > string's hash (KHK). The directory contains the CHKs of the actual files > (stored separately). A fixed array of CHKs is not enough - a malicious user > could quickly squat all 256 keys for a given artist+song string, for example. > What we need is a dynamic list of CHKs accessed via a single KHK. Quite simple, since KHKs will only store references to CHKs. BTW, KHKs aren't used, KSKs are. > > PROBLEM 3: WHEAT AND CHAFF > > Let's assume that those who oppose the free movement of information aren't > stupid. Realising that freenet can't be shut down by a court order, sooner or > later they will use technological means to try and close it down or make it > unusable. Obvious attacks include running malicious nodes, running malicious > clients, discovering nodes and attacking them by out-of-band means, and (to > prevent music sharing) submitting dummy encodings of songs which either squat > keys or waste users' bandwidth. Dummy encodings won't work if you use CHKs as they were intended. > Freenet is designed so that files which are requested a lot spread around the > network; files which are never requested eventually disappear. To exploit this > mechanism, we need to be able to check the quality of an encoding without > downloading it. We need a way for users who have previously downloaded the > encoding to tell us whether it's worth downloading. > > My solution is Slashdot-style moderation. This style of moderation is fairly > robust - at least, it does not allow vote-stuffing. You can only moderate > when you are given moderation points, which happens randomly and > infrequently. For Freenet it would work like this: Moderation allows censorship, and thus isn't a good idea. The way to handle bad data is to allow people to sign documents when they insert them, so that you would pick a document out of noise because you trust the (anonymous) person that signed previous good ones. > > PROBLEM 4: WE'RE NOT IN FREENET ANY MORE > > If this is supposed to be a quick hack to keep Napster fans happy, it won't > work. My design requires the following extensions to nodes: > > They must be able to route messages to the node storing a given CHK. > This possibly opens up the network to DoS attacks (?). This is > required for moderation. Very bad. > They must be able to route messages to the node storing a given KHK as > well, to allow entries to be added to directories. Again, DoS. Very bad. > They must understand the message "add this read key to the directory > with this KHK". Spam. > They should also perform some directory management tasks during idle > moments: > > * Check that a new entry really exists by requesting the file > it points to. > > * Retrieve two files, decrypt them and compare them. If they > are the same, remove one of the directory entries. Censorship. This cannot be handled by a client. The whole variable encryption thing stinks. Encryption already is done in a manner that eliminates duplicate documents. > Any thoughts? Why is your last name in all caps? Just curious. Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000728/3b53b287/attachment.pgp>
