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 eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
