On Thu, Jun 26, 2008 at 02:22:00PM +0200, Cedric BAIL wrote: > On Tue, Jun 24, 2008 at 7:27 AM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman <[EMAIL PROTECTED]> babbled: > > > >> I'm not exactly sure what you are planing to push into and pull out of > >> this API, but it might be more sensible to provide the key on open. And > >> then use a scheme like CBC to encode a stream of data until it is done. > >> Then close. Or in other words; start(); add_data()...; finish(); > > > > as eet files can store multiple (independent) data segments - addressed by > > key > > strings (like a tar.gz with multilple files in it) it makes the most sense > > for > > the key to be provided along with reading/writing a specific data segment - > > no? > > > >> Having a pool of registered keys might make sense if it is envisaged > >> that more than one might be used at a time - though not on the same > >> set of data. > > > makes sense if we consider the whole file encrypted, but as such why limit > > it > > to a set of keys you have to set up in advance (other than performance)? :) > > The idea of setting up the key in advance give us the possibility to > set them outside of the direct user of the eet file. We can cypher an > edje collection and without any modification to edje library use it. > Same goes with any user of eet, no need to change it. Only the apps > that want to use this feature will need a change (and of course they > will need it as they need a way to provide the key).
Another issue may be if keys need to be unlocked using a passphrase or other wise initialised in an interactive or expensive way. If that were the case it would make sense to initialise each key once per session rather than each time a read() or write() was performed. Cedric, with regards to your initial question of using an existing scheme or creating a new one. I would suggest the former as getting such scheme right can be tricky, so its usually better to use established methods. -- Horms ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
