Hi, On 10/9/07, Kent Yoder <[EMAIL PROTECTED]> wrote: > Hi Alon, > > > Here you are wrong. > > pkcs11-helper provide the ability to access the PKCS#11 industry standard. > > Please try the patchset and see for yourself that the solution allows > > eCryptfs to access any PKCS#11 provider. > > I understand, I'm just pointing out that its non-standard ways of > doing things will not be acceptable for some, so we should name it > something unique.
Why none standard way? pkcs11-helper uses standard PKCS#11 calls to a standard PKCS#11 provider. Application that uses pkcs11-helper use standard PKCS#11 providers. Since PKCS#11 standard is not closed standard in term what needed to be supported, how and when, using PKCS#11 is very complex task. Implementing the same complex task in many applications time after time is not wise, this why software engineers came up with this great idea of code reuse, shared library or dll. You implement a complex task one time and allow many applications to use it. Fixing/improving the library affect the whole chain, so everyone happy. But I am sure you know all the above... But for some strange reason you think PKCS#11 is an exception... I cannot figure it out. > > Why? It takes about 2 seconds to do this using most smartcard > > hardware... And less than 0.1 second to do this on main CPU... > > Why should it? PKCS#11 was designed in such a was that what > pkcs11-helper is doing shouldn't even need to happen. Under the > covers of your smart-card token you should implement the RSA > mechanisms with an openssl interface. All operations then just flow > through PKCS#11 in the same slot and token with no need for a new > interface. Worst case you could use a separate software only slot and > *still* not need multiple PKCS#11 providers. You are wrong. PKCS#11 was designed to allow flexible implementation, so flexible that you don't have to implement almost anything. >From my experience, and please let's assume you accept that I have some experience in this field, most providers implement the minimum required functionality. Another wrong statement you have written is "... that what pkcs11-helper is doing shouldn't even need to happen" pkcs11-helper does not do anything! I have OpenSSL interface to ease integration with OpenSSL enabled applications. The eCryptfs OpenSSL key module was a great place to start. Also, please note that there is advantage of using public key cryptography without requiring the token to be available. For example, Opening a new file at eCryptfs does not require any token to be available, or adding keys into the keystore during login does not require the token to be available. > > I already told Michael that if we want *ACCELERATION* we should divide > > private and public key operation, so that public key operation may go > > to the accelerator and private key operation go the the specific > > provider. The accelerator and provider may be the same module, but in > > most cases they should be different. > > Why? I've not seen this, and it strikes me as a design flaw as I > said above... You work at IBM LTC security, right? You guys must have a lab with many smartcard types, you can see if I am right or wrong. But anyway this discussion is irrelevant, as I am offering you to have PKCS#11 feature *NOW*, if you wish to implement a different implementation, you can, nothing should be changed in any of the interfaces, you wish to drop OpenSSL usage, pkcs11-helper usage etc... Just do it in the future, why holding feature from users? In the mean time we improve eCryptfs implementation so it will enable support of dynamic hardware configuration. 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
