On 10/9/07, Kent Yoder <[EMAIL PROTECTED]> wrote: > Pulling keys out of a PKCS11 store and encrypting using openssl is > not talking pure pkcs11. So we'll name the provider pkcs11-helper. > Is that ok?
Which keys? The public keys? I really don't understand what wrong with it. > I see the problem here -- PKCS#11 providers suck. :-) You have no > control over what they implement and since none of them have > implemented any software slots in their providers, you're forced to > use a workaround (pkcs11-helper). But these providers are out there, there is no point in supporting none existence perfect provider... Your application just won't work. > That's too bad, but it doesn't > change the fact that some providers don't suck, and code will use one > provider at a time and only interface to that provider (no external > openssl interface). I already wrote to Mike that I have no objection to use C_Encrypt if it available on provider, but please note that if it is not available we still need to use OpenSSL or similar API to complete the missing functionality. What I think you don't understand is that pkcs11-helper does not require the public key cryptography to be done using OpenSSL, and that PKCS#11 implementation *ALLOWS* provider not to implement public cryptography. So you can say that PKCS#11 sucks, but supporting PKCS#11 does require you to handle this situation. > Therefore, we must have a pure pkcs11 interface > in ecryptfs, therefore, your helper must have a different name. That > is seriously what this issue boils down to for me. As I said, if you develop pure pkcs11 interface I won't compete with you. There is no reason to have several PKCS#11 implementations. > No, its not an exception at all. Some time in the future, there > will exist a token where we will want to call C_Encrypt and C_Decrypt > using the PKCS#11 key handle, straight from the ecryptfs PKI API. > That's the use case that keeps us from calling your token interface > "pkcs11" instead of "pkcs11-helper". You don't understand... You still will require to use C_Wrap or C_Unwrap, still manage sessions so that users will be asked one time for PIN for each token, handle token removal and insert, handle protected authentication and much more. The encryption issue is the most irrelevant one, but I fail to explain this to you (so far). Also please note that in future eCryptfs will likely need to support signature, so that the configuration file may be signed so root may not alter it... So on top of all you need to support C_Sign or C_SignVerify and in turn by your approach verify the signature using the token. Please mind that encryption usually done on one computer where the provider is not available and decrypted on computer where a provider is, and that signature usually done on one computer where provider is available and verified on computer where is not. Let's say that you encrypt mail using S/MIME to your friend, you don't have access to your friend's provider and you encrypt your mail, you can also sign it but your friend cannot access your provider... So please note that public key cryptography is implemented in software and not by the provider holding the private key. Public key cryptography acceleration may be added, but please understand that it has nothing to do with the private key provider. eCryptfs is a confusing environment as encryption and decryption are performed on the same machine, so it is very easy to be confused and think that both operations needs to be performed at the same provider. > This just goes back to my previous point, you have no control over > what's going into these providers, and so they lack s/w fallback. > Those using a provider that does provide s/w fallback shouldn't have > to go through your extra layer. But if performance of C_Encrypt is about 2 seconds, do you prefer not to use extra layer? Strange... > I haven't read all of this thread, but I haven't heard anyone say > your feature won't be accepted. As I said before, I won't compete with you guys. eCryptfs and users don't need two separate implementation for PKCS#11. As I suggested before, you can begin with my implementation and later on if you decide that you can do better, just replace the implementation. But we need to work together on this one, not compete with each other. Apart of implementing the PKCS#11 key module there are lot of changes need to be done in eCryptfs implementation to correctly support dynamic hardware cryptography. These efforts will payoff even if you switch to another PKCS#11 implementation. But if I read you correctly the PKCS#11 key module you think need to be implement will support about two providers, so you also cannot call this PKCS#11 as you don't support the complete standard (what you call suck providers), these provide may be suck, but they are compliant to the PKCS#11 standard, and if you don't support them you really don't do PKCS#11. 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
