On Tuesday 22 July 2008 23:21, Robert Mead wrote: > So it sounds like it will be about as secure as it currently is, but a > lot more efficient. 5 to 3 is a big difference. > > How about opt-in for the next version? I'd turn it on.
It's configurable, but we have to decide what the default will be. > > Matthew Toseland wrote: > > So far, various solutions to FOAF-routing vulnerabilities have been proposed: > > > > 1) Limit an opennet peer to advertising 19 of its peers' locations (plus > > ours). Nextgens has implemented this. It's not a full solution. We need to > > impose some limit on darknet peers too, but even then, a clever node could > > still get most of our traffic. > > 2) Limit any single node to no more than X% of the keyspace, or detect and > > disconnect from nodes which occupy more than X%. The problem here is that it > > is entirely legitimate for a node to have most of its neighbours near its > > specialisation, and a few "long links" covering large areas of the keyspace. > > This is in fact exactly what is supposed to happen! > > 3) Limit any single node to no more than 30% of our outgoing requests. This > > would help in that getting 100% of a node's outgoing requests wouldn't be > > possible... but it wouldn't solve the problem. If an attacker's objective is > > to capture all the locally originated traffic, he just needs to grab as big a > > part of the keyspace as possible, excluding the target's specialisation as > > most of its non-local requests will be in that area. > > 4) Limit any single node to no more than 30% of our outgoing *locally > > originated* requests, in addition to a limit applying to all requests. The > > worry here is that an attacker might use it to distinguish between locally > > and remotely originated requests. > > 5) Attempt to enforce a 1/n distribution of locations. IMHO this is probably > > unrealistic in real world routing... > > > > Background: even without FOAF routing, an attacker who is directly connected > > to the target can probably identify any known content with reasonable > > certainty, by performing a correlation attack. This won't dramatically change > > until we implement some form of encrypted tunnels... > > > > Thoughts? Nextgens simulated the current (disabled) code on a perfect 500 node > > network and saw average hops reduced from 5 to 3 ... > > > > Should we enable FOAF routing anyway, and if so, which mitigation measures do > > we need to implement first? Note that encrypted tunnels would not solve this > > problem, as they are impacted by it also (if we do rendezvous at a key, and > > use FOAF-routing; random walk rendezvous wouldn't be affected). > > > > On Friday 18 July 2008 15:42, Florent Daigni?re wrote: > > > >> Yesterday I have implemented and committed the naive > >> implementation of foaf into the trunk... (foaf routing : > >> http://archives.freenetproject.org/message/20080707.111733.13824377.en.h > >> tml) > >> > >> I am reluctant to enable it by default as they are some major security > >> implications. As far as I understand, the logic was: "the swapping > >> algorithm can already be subverted by an attacker to extract our peers' > >> location... hence implementing foaf won't harm much: it will just > >> provide more accurate data to a potential attacker". > >> > >> Foaf-routing is about two things: > >> 1) publish our peers' location > >> 2) use the intelligence our peers provide us to route more > >> effectively > >> > >> While the old logic covers point 1 it doesn't cover point 2 and we have > >> to ask ourselves how point 2 can be used by a bad guy... > >> > >> The obvious attack scenario is: > >> The attacker has a direct link to my node. For his attack to > >> succeed he would like to capture all my outgoing traffic (in > >> which case it's obvious I don't have any anonymity). It is > >> trivial to do on a foaf-enabled node; The routing algorithm > >> always route to "the closest location it can find"; The bad guy > >> can advertise several locations for his node (pretending he is > >> peered to some nodes who have the locations he wants them to > >> have). The bad guy also have an accurate view of my peers' > >> location as I have cleverly sent them to him... > >> > >> If he advertises two peers for each of my peers with a location > >> slightly closer and slightly further on the keyspace (say +/- > >> 0.000000001), my node *will* send every requests to his node! > >> > >> It's obviously a problem we will want to address somehow... > >> > >> One option is to limit the amount of locations he can advertise. It is > >> an inefficient mitigation measure as he doesn't need many of them: the > >> average node has 20 links... so he would only need to advertise 2*20=40 > >> locations to cover all the keyspace. > >> > >> An other solution would be to compute the proportion of the keyspace > >> each node controls... That would be an efficient mitigation measure... > >> Moreover we could use that metric to determine whether a clustering > >> attack is going on or not... and decide whether we should randomize our > >> location or not. Of course it means introducing some more alchemy into > >> the algorithm and the code... but I don't regard the current solution as > >> acceptable. > >> > >> Can anyone think about some other mitigation measure we could use? > >> Is anyone willing to run some simulations and find out the magic-values > >> we are going to use in the mitigation algorithm? > >> > >> NextGen$ > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Devl mailing list > >> Devl at freenetproject.org > >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080722/e4dc4d44/attachment.pgp>
