On Wed, Oct 15, 2003 at 06:14:21PM -0700, Martin Stone Davis wrote:<snip>
D'oh!!! I goofed: Node C would see that it takes node A LESS TIME to find keys K101-K1000 than to find keys K1-K100, since A is trying to hide the fact that it has K1-K100.Say that over a long period of time, node A requests keys K1-K1000 from node B. K1-K100 were requested by the operator of node A, while K101-K1000 were requested by nodes connected to node A. Also, K1-K100 are all related to documents describing plans to overthrow the evil government of AAIR (it's a tropical country which depends mostly on tourism). Node B is run by (you guessed it) the AAIR. At the same time, the AAIR is running another node C, which mounts a timing attack on node A to see whether it has keys K1-K1000. Under either solution #1 or #2, node C would see that node A takes longer to find keys K101-1000 than it does to find keys K1-K100. But since the AAIR know that node A
Either you don't understand because I goofed (see above) or because you didn't know the following: when I speak of K1-K1000, I'm naot talking about keys 1 through 1000 in the keyspace. I'm talking about some vector of keys in which I'm indexing each element by a number 1 through 1000. The keys are distributed in the keyspace in some more-or-less uniformly random way.requested all of the keys, it also knows that the operator of node A requested keys K1-K100 and is trying to hide that fact.
Note that in the above scenario, K1-K100 don't have to be part of the same splitfile. They just have to be of similar-enough subject matter that the operator of node A would appear to have requested it IF someone were to inspect his datastore.
Hmm. I don't understand - why would they be accessed more quickly? Keys related in content are not related in the keyspace.
Does that clear things up?
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
