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). -- Cedric BAIL ------------------------------------------------------------------------- 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
