On Thu, Oct 16, 2003 at 10:28:15PM +1000, fish wrote: > 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).
I am not sure where would be the best level to implement it yet. > 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. Actually, it needs to be a key PER FILE. The files have randomly generated filenames. We keep both the decryption key and the data key in RAM at all times. We do NOT want to reimplement the monolithic datastore, the filesystem is quite capable of storing files. > > 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 Right. > > (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...) Don't bother padding them. The fact that most of your keys are 1MB rather than 256kB doesn't tell an attacker anything about the content. I suppose we could have padding as an option. But it's wasteful, and you have to generate cryptographically safe padding, which is expensive. The keys are ALREADY padded to fields + power of 2. Fields is not metadata, it's a fixed size piece of data that varies depending only on the keytype (although I believe it can occasionally be 1 byte shorter - anyway we can pad fields if it is useful). > > > 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 -- 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
