* Matthew Toseland <toad at amphibian.dyndns.org> [2008-07-18 20:33:10]:
> On Friday 18 July 2008 18:08, Florent Daigni?re wrote: > > * Daniel Cheng <j16sdiz+freenet at gmail.com> [2008-07-19 00:57:53]: > > > > > On Fri, Jul 18, 2008 at 10:42 PM, Florent Daigni?re > > > <nextgens at freenetproject.org> 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 > > > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > not "two peers for each of my peers", but "two peers for each of my > > > peers' peers". > > > i.e. 20 * 20 * 2 = 800 > > > > > > For he does not know my peers' peers, this is not that easy. > > > (although this is still possible, when combine with the information > > > from location swapping) > > > > > > Do you feel better with this? > > So we're agreed that the original attack (one location to either side of each > of our peers' locations) doesn't work? Heh, I called it the "obvious attack scenario": I have no doubts that it can be improved. I wouldn't say that it doesn't work; I would say that it's not as effective as I thought initially. > > > > No :) > > > > Atm the only limit is the size of the field in the DMT message. We allow > > a ShortBuffer which is 32kB... A double is 8 bytes meaning that the bad > > guy can advertise 4000 locations. > > This leaves two possible attacks: > 1) Use swapping to work out our peers' peers, and do the 1-at-each-side > attack. > 2) Just advertise tons of locations. > > /me notes that if the advertisement packet is over 1kB we may run into severe > MTU problems on many connections ... so we could limit it to 128 for > practical reasons. But that would certainly be enough for attack 1 and > probably enough for attack 2. That's a limitation of the current transport scheme... Luckily for the bad guys we are going to switch to a stream based one ;) NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080718/403a25bd/attachment.pgp>
