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? 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$ _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
