On Fri, 23 Mar 2007 2:13, Gabriel Ambuehl wrote:
I'm not entirely sure why one would need a new FUSE driver then.
Can't you just use encfs (I gather you don't want LUKS because it needs
setting Filesystem size in advance and I can see why one would want to
avoid
that [1]) and tell the apps to either use the encrypted tree or not?
Then any
app can be made to use the encryption features by virtue of providing
it with
proper paths.
One important thing eventually will need to be the ability to encrypt
data written from applications which don't know about the encryption
system.
If I am in a notes application and I write a note, ideally you would
have some kind of db holding all of that information.. The
implementation of the db is not important to my discussion at this point
and for all I care it could be some daemon on top of an xml file or
sqlight (sp?) or what have you.. When you encrypt it, it should be
secured. Now in a db you kinda have to be careful because people will
want to fill up the column space with normal characters. When we
encrypt, that might (probably) increase the actual datasize right?
Encrypting "the cow is blue" which contains 15 characters may require a
pad to 16 and then block encrypted may be larger then 16, right? That
all depends on the method of encryption I guess.. Maybe some will be
exactly 16 or if its not a block encryption algorithm maybe it can just
encrypt the 15 bytes into 15 other bytes? Anyway, the method would need
to be independent of the application somehow.
I like the idea of having 2 storage paths... One encrypted and one not.
From my very quick and non-authoritative glance at unionfs we could make
2 trees, one encrypted and one not and have it make them look like one
path. Its not clear to me how we make sure we write to the encrypted
one on demand however..
I have not looked at pefs but if it does like joe indicated then it
handles the encryption/authentication stuff.. So all we need to do is
somehow mirror and join the db calls or filesystem reads/writes between
the encrypted and non-encrypted filesystems and voila.. You have it all
working and for the most part, transparent. The transparent piece
requires the interception of low level api though... In order to capture
the read or write before it hits the filesystem unencrypted.
I grant you, all of the above is a huge oversimplification of the
process. (Grin)
Things like unmounting on inactivity etc can easily be handled by a
small user
space daemon running besides FUSE then. And if you want to provide
different
levels of security, simply add more trees...
How would this work from a db perspective? If a notes application does
not know about encryption and just knows to save data... And it uses
some kind of a db file to do it, how do you secure that partially? One
note secure and one not? If it used files for each note that would be
easier, but in a db? It seems like you would have to mirror the db file
itself and somehow join them together before the read in order to get it
working and that seems way too complex. At the moment I don't see a way
without encryption the entire db. The application probably won't be
expecting 2 dbs and won't know how to handle it. /shrug
--Tim
_______________________________________________
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
