On Wed, Oct 15, 2003 at 06:14:21PM -0700, Martin Stone Davis wrote: > AFAIK, it is possible right now to discover whether a node has requested > a particular large splitfile by measuring how much time it takes the > node to search for each part of the splitfile. > > To prevent such "timing attacks on the datastore", I thought at first > that a solution would be > > SOLUTION #1: that the the node itself would flag any keys that the > operator has requested as "requested only by me". Then, if the node was > asked later for a key that held such a flag, it would pretend that it > didn't have it, search for the key on other nodes, and then reset the > key's flag if it found it on another node. > > However, Iakin (I believe) pointed out that this is a bad idea because > we don't want freenet itself to break it's own anonymity: we don't want > someone to be able to inspect the operator's hard drive and say "ah ha! > you requested this key!". > > He suggested instead (if I understood correctly) > > SOLUTION #2: that keys that we request would somehow be moved into a > separate, encrypted store, and never placed in the main datastore.
Quite possible WITHOUT reimplementing the monolithic store. What I mean is, I do NOT want the user cache to be implemented as a single file. The way that we should do this is to store the files in a temporary directory that gets wiped on startup, using opaque filenames and keys stored only in RAM - but one file for one key. Since we pad out to powers of two, the leak of data from knowing the sizes of the files is negligible. > > However, isn't there a problem with that as well? > > 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 > 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. > > > I'm having a lot of trouble coming up with a good solution. Thoughts? > > -Martin -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
