Here at DEFCON it has been pointed out by the Gnunet guys that we are creating a node location by combining locations supplied by two different nodes by taking one to the power of the other. Nice that *somebody* is reviewing our code :-)
If true, this is a *serious* error, and could be the reason for some of the weirdness we are seeing in node location clustering. Math.pow(rand(1.0), rand(1.0)) may result in a number between 0.0 and 1.0, but it will not have a uniform distribution across this range. I suspect the problem here (after discussing it with Oskar) is that when he outlined the problem, he described it as A^B - however he intended ^ to mean bitwise XOR, *not* the exponent function. If this is the case, then we need to fix ASAP - although it shouldn't cause any network incompatibility. The Gnunet guys did a talk here about how it is possible to cause node locations to become highly clustered through attacking the location swapping mechanism. See: http://defcon.org/html/defcon-15/dc-15-speakers.html#Evans Despite the rather dramatic tone of their abstract, this was a problem that Oskar identified when he first came up with the location-swapping algorithm. Also, despite the fact that they claim the flaw cannot be easily addressed, it is entirely possible that it can actually be easily addressed by periodically resetting node locations (they outlined this possible solution on a slide in their talk but didn't talk about why they believed it wouldn't work). Location resetting was also Oskar's initial thought on how to counter this attack. Of course, if we reset node-locations too frequently then it will interfere with convergence to a good network configuration, so we should probably do some experiments to figure out a good balance. There is another possible solution which they suggested (not in the talk, but in a discussion afterwards) where we keep an eye out for locations are too close together based on a very rough estimate of the maximum network size. Clearly this is ugly, but could be effective in practice. Anyway, props to the Gnunet guys for raising these points, hopefully they will continue to help us identify or highlight potential problems. Ian. -- Founder and CEO, Thoof Inc Email: ian at thoof.com Office: +1 512 524 8934 x 100 Cell: +1 512 422 3588 AIM: ian.clarke at mac.com Skype: sanity
