Michael T?nzer wrote: > How about a combination of HTL and weighted coin: We don't only > decrement probabilisticly at 10 and 1 but on all the way down from 10 to > 0
Sounds interesting... the current HTL would give an attacker a known distribution of probabilities over the number of hops the request has travelled so far. However, compared to a weighted coin with the same mean path length, an attacker would have higher confidence that a request with high HTL originated at the previous node. > and flip the coin each time so no (100% sure) assumption can be made > what we will do next time. As Matthew said, that would be vulnerable to statistical attacks. > If our location is closer than > the closestLocation we don't set closestLocation to our actual location > but to a location a little bit _closer_ (if we set it to a location more > far away the next node knows we reset closestLocation), this is also > done probabilistic, and set the HTL to a value between 8 and 10 (more > likely to 10 than to 8 - maybe we could even set it to a value between 1 > and 10 but make 1 extremely unlikely e.g. > (int)(11-10*Math.pow(PROBABILITY_TUNER,(-Math.random()))) where > PROBABILITY_TUNER is 10^(1/(1-(Probability of HTL=10))) ). > To add even more fuzz we could even make the probabilities a partly > random value. So every time the node is started it calculates the > probabilities to decrement the HTL per possible HTL-value. Of course we > had to limit that but again I would speak for letting them be everything > but making it more likely to be a suitable value. The problem with complicated systems like this is that we don't really know how much anonymity we're providing; an attacker might be able to find a flaw that we haven't spotted. It's basically security through obscurity. Cheers, Michael
