On Sun, Oct 26, 2003 at 03:45:27PM -0500, Nick Tarleton wrote:
On Saturday 25 October 2003 02:42 pm, Martin Stone Davis wrote:
Nick Tarleton wrote:
On Thursday 16 October 2003 10:11 am, Martin Stone Davis wrote:
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.
What if it moves them from the separate to the main store when they pass through it without client intervention? I.e., if it receives a request for K1, it goes through the network and THEN moves K1 to the regular store.
Sure, but the problem still remains: the evil AAIR would still be able to tell that I was trying to hide the fact that I had requested K1-K100, since it will detect a timing difference where it knows there would be none if I weren't trying to hide it.
Then why not put a random fraction of keys in the regular store? (Alchemy.)
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.
This has been dealt with as far as I am concerned. All we have to do is cache normally - in the short term, cache if and only if pcaching says so, taking into account client access, and have a higher level cache of only what is requested by the user, which is not accessible to requests from off the node, which always caches in a strict LRU, is wiped on startup, and uses one-time in-RAM encryption keys.
...which protects us from the "You have too many naughty keys" attack. To protect us from the "You tried to HIDE too many naughty keys" attack, we also need premix routing. Right?
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
