On Mon, Jun 29, 2009 at 3:28 PM, Matthew
Toseland<toad at amphibian.dyndns.org> wrote:
> On Monday 29 June 2009 17:03:56 Gregory Maxwell wrote:
>> On Fri, Jun 19, 2009 at 12:37 PM, Robert
>> Hailey<robert at freenetproject.org> wrote:
>> > What about an evil peer sending a "full" filter to try and collect all
>> > traffic? Have we discussed that?
>>
>> Might it be reasonable to weigh the selection with the selectivity of
>> the filter?
>>
>> I.e. weight = 1.0/(abs(number_of_ones_in_filter - number_of_zeros_in_filter))
>>
>> (or, instead, weighing by the ones density compared to other peers?)
>>
>> Regardless of the security properties, some kind of density based
>> weighing is probably be desirable in terms of traffic balancing to
>> avoid nodes with dense filters capturing too much of the traffic.
>
> IMHO our current defense (prevent any node from getting more than 30% of 
> outgoing traffic) is adequate, probably combined with an attempt to identify 
> when a node is unable to send the key it advertised. Bloom filters are not 
> the only way to get more hits from a peer, look at FOAF.
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>

Nonetheless, the node should probably detect and reject obviously
bogus filters (whether malicious or buggy), defined as (fraction 1s) >
(some threshold).

Bloom filter false positives (regardless of cause -- bad luck, out of
date, or malice) should be rare; treating them like any other transfer
failure might be wise.  Attacks based on malicious filters are
somewhat different than FOAF attacks: they can target a large number
of keys spread across the keyspace, rather than an isolated region (or
two) of the whole keyspace.  I don't know how powerful they are in
practice (I suspect not very) but they're worth being aware of.

Evan Daniel

Reply via email to