> > > >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). Like I said, this is already done. Its not an RC4 key (which, btw, is a questionable block-cipher with known attacks).
> >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. Ask Alex Barnell, he's better at describing it than I am. > >HUGE problem with spam. > > Of course, but that's what moderation is for. I disagree, but opinions are like assholes. > > >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. The whole directory business is questionable imho as well. Subspaces (which have some shaky issues) solve the same problem in a much better way. > >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... CHK encryption. This is a non-issue. Read up on how CHK encryption works, and you'll be enlightened. > >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. Trusting a group of people you don't know is questionable as well, but your right, if your only talking about music it would work. However, I want to see solutions that work for what Freenet is intended, ie trafficing of all free-speech material. > >> > >> 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. Yeah, but Freenet isn't a network, its a datastore, so I argue that adding this feature would be like shooting Freenet in the foot. > > >> They must understand the message "add this read key to the directory > >> with this KHK". > >Spam. > > Moderation. Blows. :) > >> * 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. Freenet isn't a music-sharing system. If you are trying to create one, go elsewhere. If you are trying to distribute music on Freenet, develop a specialized client, but don't go mucking about in the protocol. > >This cannot be handled by a client. > > No, it is handled by the node holding the directory. Again, way too specialized for a node. > >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. Yes, and thats exactly how it *does* work. The CHK when found by a user includes its decryption key. But the decryption key doesnt travel with the key on insert, so only people knowing both the CHK and its key can do anything with it. > >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) Edit your pine preferences from SETUP. -------------- 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/e9ad72bd/attachment.pgp>
