On Thu, Oct 16, 2003 at 03:30:06PM +0100, Toad wrote: > 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.
I used to think at fproxy level, but I've since changed my opinion, because
I think it would be beneficial to provide this functionality to FCP based
clients as well
> 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.
It actually is per file, my phrasing was just unfortunate.
> 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).
noted.
-- 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
