Hello Michael, I guess we are back on business? Can you please address these point?
Thanks! Alon Bar-Lev. On Tuesday 16 October 2007, Alon Bar-Lev wrote: > Hello Michael, > > Here are some of my thoughts regarding the key module interface. I > wrote some in the past but I got no response regarding this. > > 1. Introduce statefull mode. > > Current implementation is stateless, every call to encrypt or decrypt > results in deserialization, create the crypto context, do the crypto > operation and release the context. > > The above is done *TWICE*, as once it is called to get size, and the > second to do the actual operation. > > I suggest adding two callbacks, one for deserialize and one for free, > the deserialize will allocate key specific context that will be used > instead of the blob for crypto operations. The free will be called > when the key is not used anymore. > > This will be much more efficient than current implementation, and will > also enable storing more data on the context so that next calls may > proceed much quicker. > > 2. Allow the key module to report that a key is unusable. > > For example, if the user specify wrong passphrase for smartcard key > (statically), and this passphrase is wrong, if more than X retries are > done, the card will lock itself. So we need a way to report that this > key is unusable, so it be deleted from store. > > 3. Key module context & parameters > > Allow key module specific parameter that are not related to a specific > key, this will allow to specify some module wide options. It should be > read from some configuration file and forwarded to the key module > during initialization.This also suggests adding key module wide > context that may be returned from module initialization callback, and > free during module termination, this context should be passed to > deserialization callback so it may be stored in the key context. > > 4. [Not directly related] Pluggable Random Generator > > eCryptfs gathers its random for the encryption keys using default > system random, but I guess it should be pluggable. I believe the > simplest way is to add sysfs entry and set a random device... Another > solution is to use the netlink socket in order to get the random. As > maybe users wish to choose a better random source for eCryptfs than > the system. > > Best Regards, > Alon Bar-Lev. > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ eCryptfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
