On Wed, Oct 15, 2003 at 06:14:21PM -0700, Martin Stone Davis wrote: > SOLUTION #2: that keys that we request would somehow be moved into a > separate, encrypted store, and never placed in the main datastore.
I talked about this once before, although for a differnet reason (I
actually implented it at GetRequestProcesS level, because I was looking
for speed for fproxy rather than trying to solve this particular problem).
A quick recap of one important point, however, if you want to talk about
implenting this at node level:
- the encryption key for the "local" datastore must only ever be stored
in ram (java actually makes this quite impossible to guarentee right now,
afaik, but you can at least only store it in virtual memroy... the point
being, not written to disk by fred, at least), and re-generated from
some random source each startup.
This is important, because if such a thing were to be implented, which
many people here already think is a bad idea for this reason, it needs
to be completly impossible (or lifetimes of the universe level of
processing power, at least) for an attacker to determine which keys are
in the local store
(in the case of the implentation i was working on, i stored things in
files padded to a mbyte, encrpyted with said one time key, and optionally
these were stored in a single large encrypted file (tho default, optional
because that extra layer of crypto really hurt my cpu, and I didn't 100%
trust the code that was encrpyting this file yet, since I was using
CryptStorage from the old DS to do it, and we all know the old ds...)
> 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.
Hrm, you could claim pcaching, if you turned on pcaching 100% of the time
rather than just at 75% or whenever it gets turned on.
-- jj
--
I'm sick and fucking tired of not getting people drunk.
-- blixco, http://www.kuro5hin.org/story/2003/8/20/105121/869
pgp00000.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
