On May 12, 2009, at 11:45 AM, Florent Daigniere wrote: > Robert Hailey wrote: >> >> On May 12, 2009, at 6:47 AM, Matthew Toseland wrote: >> >>> ... >>> So the question is, how practical is it for a mobile attacker to >>> identify a >>> block in its neighbours' stores (from the bloom filter), get >>> connected to the >>> neighbour's neighbours, download their bloom filters, and trace an >>> insert or >>> request back to source one hop at a time? >> >> At first thought, I would imagine if bloom filter sharing increases >> the fetch effectiveness by x20, so to it would make such an attack 20 >> times easier. A powerful attacker might track ~everyone's~ bloom >> filter!!!! >> >> What would the security implications be if we were to have the node >> with the store check the bloom filter rather than sharing it (~one- >> hop- >> probe~)? Would that buy us anything, being able to mete out bloom >> filter checks? Then such an attacker could not check to see if we >> contained ~80% of a split file because he would have to ask us to >> check our bloom filter for so many keys. It would also be an order of >> magnitude easier to implement than "sharing". >> > > Huh. > > What are you suggesting here? That we re-invent the current protocol?
Sort of... but a request which does not route; one which only checks the datastore for the presence of a key. I believe that this idea was rejected earlier since the request "does not propagate the requested data," but appears to be much better security-wise than bloom filter sharing. And we could convert a fraction of these probes into full requests if we wanted to. > The whole point of sharing bloom filters is to get rid of the > network/node latency. We already have local bloom filters to avoid > unnecessary datastore lookups. > > NextGen$ If the bloom filters are recovering already-failed requests, then surely latency is not the issue being addressed. I thought that the point of having bloom filters was to increase the effectiveness of fetches (a more reliable fallback). -- Robert Hailey _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
