On Friday 18 July 2008 20:49, Florent Daignière wrote: > * Matthew Toseland <[EMAIL PROTECTED]> [2008-07-18 20:33:10]: > > > On Friday 18 July 2008 18:08, Florent Daignière wrote: > > > * Daniel Cheng <[EMAIL PROTECTED]> [2008-07-19 00:57:53]: > > > > > > > On Fri, Jul 18, 2008 at 10:42 PM, Florent Daignière > > > > <[EMAIL PROTECTED]> 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 ;)
Well we should figure out a reasonable maximum. > > NextGen$
pgpQcbFijI33u.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
