Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

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