>> 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
The point isn't to prevent nodes seeing what they're storing - that's a side effect. The point is to associate a file with an RC4 key which the requester holds but the node storing the document doesn't. This stops the node from tampering with moderation. Also it allows you to store multiple copies of a document (yes, there are pros and cons to this). >> 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. Maybe. I'd like to hear how freenet would avoid the close keys attack I outlined in my previous email. (I'm not saying it can't, but I'd like to hear how it does/would.) >> 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. How will searching work? Again, I'm not arguing, I'm just asking for info. >> 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. Of course, but that's what moderation is for. >> What we need is a dynamic list of CHKs accessed via a single KHK. >Quite simple, since KHKs will only store references to CHKs. Yes. >BTW, KHKs aren't used, KSKs are. OK. The node holding the directory holds the private key to the directory's KSK and is thus the only node which can update the directory's contents. Good. >Dummy encodings won't work if you use CHKs as they were intended. True - but then how do you associate a file's moderation tokens with the file without letting the node which stores the file (and the tokens) fiddle with them? I need to think about 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. But to do that, you have to find out the public keys of some providers, experiment, and build up a list of trusted providers. Moderation might allow the group to censor the individual, but assuming that most of the group wants the same things (music, not spam) I don't think that will be a problem. For freenet in general it would, but not for a music-sharing system where 99% of the users agree on what they want. So you trade the danger of censorship for the convenience of an "instant-on" system where you don't have to spend any time working out who to trust - you just trust the group as a whole (or on average) to moderate in their own interest. Moderation tokens are reasonably safe from vote-stuffing by a few determined individuals, particularly if you give them out at the end of the download, so the vote-stuffer has to d/l the whole file several times to get a token. >> 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. Potentially very bad. Maybe there are some flood-avoidance tactics we could use. >> 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. See above. >> They must understand the message "add this read key to the directory >> with this KHK". >Spam. Moderation. >> 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. Only a problem if the majority does not agree on what should be censored. And in a music-sharing system, the majority does agree. Spam should be censored. >This cannot be handled by a client. No, it is handled by the node holding the directory. >The whole variable encryption thing stinks. Encryption already is done in a >manner that eliminates duplicate documents. Well don't mince with words Scott, tell us what you really think. ;) I will look into removing the variable encryption thing. The file just has to have a key associated with it which the requester knows but the storer doesn't, I guess. I don't suppose it has to be encrypted with it, if the close key attack isn't a problem. >> Any thoughts? >Why is your last name in all caps? Just curious. Because I always SHOUT IT! I'm using a university email account and I can't work out how to change it. :0) Michael _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
