On Tuesday 12 May 2009 17:57:04 Robert Hailey wrote: > > 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).
So your proposal is that we broadcast all our requests to all our peers, and then what, wait for all their responses before routing outwards?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
