On Fri, 28 Jul 2000, you wrote: > >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).
If the requester knows it, then it is public knowledge (unless the requester and inserter are two specific parties already in conversation). <> > >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.) To the extent that it suffers from these issues your version does not help. If a requestor can find the key to decrypt the data, so can an attacker. If you want to create a CHK that can't have been guessed by people who have the data, simply pad the data with enough random bytes. * after reading below * You seem to have the idea that a document on Freenet wanders to a certain node that is then where it must be retrieved. This is not so, a document has no home, only possibly a node that serves it more often then any other. If that node is knocked out by a DoS or alike, it might take Freenet some effort to route around it (the next couple of requests will require more hops) but the point with the duplication is that the data not be lost. > >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. RTF docs/archives/faqs. > >HUGE problem with spam. > > Of course, but that's what moderation is for. And how in the world does moderation work in a distributed system? You can let anybody vote, but that simply moves the spam one step (spam votes rather the data). If you have a version of implementing a trust network used to allow nyms to moderate things within a zero trust distributed environment I would be _very_ interested to hear it. * after reading below * The idea that some magic entity should assign and keep track of moderation tokens is not the answer, since that entity then has to be centralized in some way. > >> 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. Having a KSK that publicly updatable (actually the same as an SVK with a publicly known readable private key) requires that we have updatability. Which we don't have yet either (though it is closer then searching). > >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... If it's a CHK then people can't fiddle with the data, period. <> > 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. Who creates the new moderation tokens after each download? Remember that the nodes arem't trusted... <> > >> 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. If this means what I think it means, then forget about it. > >> 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. You can never route anything to a particular node on Freenet, only to a particular data (which is duplicated by demand). <> > >> 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. But your trusting the node again. > >This cannot be handled by a client. > > No, it is handled by the node holding the directory. Which you can't trust either. <> > >> Any thoughts? Your system has more holes in it then a swiss cheese used for target practice with an uzi. <> -- \oskar _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
