But couldn't 50 (or some other) % come from chance? What would give a negative on BOTH attacks? And when the keys are unpopular... ehh. I had an idea a while back that could help that, where nodes that need to fill their datastores can request other nodes to send them random keys.
-----Original Message----- Here's what I see is wrong with that: The reason that setting it at 0% was problematic in the first place was that the AAIR would reasonably determine that we requested at least one of K1-K100 if we are shown to have all of K1-K100. That is, if we somehow have "enough" of the Anti-AAIR stuff on our node, then the AAIR would justifiably accuse us of being Anti-AAIR. So if we don't hide any the requested keys, we'll be discovered by the "You have too many naughty keys" attack. If we only cache, say, 50% of the requested keys, then it will take AAIR twice as long to discover us by the "You have too many naughty keys" attack. If we cache only 10%, then 10x as long. If 0%, then that attack will never work. On the other hand, if we cache 0%, then the "You have tried to HIDE too many naughty keys" attack will work perfectly. If we cache 50%, then it take would take twice as long for this attack to work. Given that the AAIR tries both attacks, the best we can do is to cache 50% of requested keys, which only doubles the time before we are discovered. > Or, keep in mind that some of K1-K100 may be in the regular store anyway, if > they passed through the node before the client requested them. They would > show as "already in store" on the timing attack, and with them presumably > having the same regular-store distribution as K101-K1000, it would be hard to > tell. Yes, the more popular K1-K100 are, the easier it is for us to hide. But shouldn't we consider the worst-case scenario where K1-K100 are not (yet) so popular? -Martin _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
