On Sun, Aug 20, 2006 at 03:17:35PM -0700, Ian Clarke wrote:
> 
> On 20 Aug 2006, at 03:36, Michael Rogers wrote:
> >
> >In the long term, might it be worth implementing a simple encrypted
> >filesystem, stored inside a single fixed-size file? The encrypted
> >filesystem could be used for the datastore, cache, client-cache,  
> >config
> >files, etc. Unused blocks would be indistinguishable from used blocks
> >because each block would be encrypted with a key derived from the  
> >block
> >number and a master key, and the master key would be derived from a
> >passphrase each time the node started up. This would make it harder to
> >examine the store of a captured node, because you'd have to capture it
> >while it was running. Just trying to save everyone some money on
> >thermite. ;-)
> >
> >This could probably be implemented as a separate library... any  
> >takers? :-)
> 
> We did something like this a few years ago, in the end we stripped it  
> out as it was a major source of very difficult to track down bugs.   
> Encrypted filesystems aren't easy to implement, but fortunately other  
> people have implemented them - I really don't think we should be  
> reinventing this particular wheel without a very good reason.

We already have a single file for each datastore. The main thing as far
as I can see is not to mix file sizes. Once you mix file sizes you get
into serious filesystem issues. But we only really need to store blocks
of 1kB or 32kB. We can certainly combine the client cache, datastore and
temporary bucket factory into one store. We can combine the datastore
and the datacache too if we keep counters for each in the database.
> 
> Ian.
-- 
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 
<https://emu.freenetproject.org/pipermail/tech/attachments/20060821/5f752344/attachment.pgp>

Reply via email to