From: "Mark J. Roberts" <[email protected]> > Are you comfortable implementing a system that won't survive a serious > attack?
The way they currently work, in-freenet indices are utterly susceptible to "serious" attacks. But we desperately need them, and until we have something better, let's use them. Thinking more generally, the core problem is probably unsolvable: we want to allow the world & dog to announce keys anonymously. Then, how can we possibly prevent anybody from announcing huge loads of crap? We can't. We don't have the person's identity. Anonymous identities won't help - you can create as many of them as you like. All we CAN do is limit the damage. Publishing a new insertion key every day is one way to do that. Another area that could use improvement is the efficiency of listing a key index. One request per key is costly. Whoopie... an idea comes to my mind: The KeyIndexClient could put a bunch of keys into summary files. It would work like this: Say, you're inserting into freegle-keys. KeyIndexClient looks for the first unused number N. Now, if N is a multiple of 10, it generates a summary file for the keys N-9 through N and inserts it into Freenet. So if N is 200, a file called freegle-keys-s190-10 (summary starting from 190, length 10) is generated, containing: <key 190> <key 191> <key 192> <key 193> <key 194> <key 195> <key 196> <key 197> <key 198> <key 199> These 10 keys will have to be retrieved from Freenet first, of course. If one of them fails to load, the summary isn't generated. This way, a part of the work of retrieving keys is distributed among all inserters. If a summary file for a given range doesn't exist, the key index maintainer will just load the individual key files. Hmm, ouch... a problem with this approach is of course that it will be even easier for spammers to corrupt the index - they can now insert 10 bogus keys at once... Jesus... -Stefan _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
