Hi Alon, > > 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.
Yes, the public keys. Some libraries keep the public key in a partially encrypted blob that is sent to the hardware to do the crypto. (Yes, the public key crypto). Of course you can pull that pubkey out and pass it around, but this isn't always the use case. > But these providers are out there, there is no point in supporting > none existence perfect provider... Your application just won't work. 1. Yes, of course those providers are out there, that's why we're accepting your code 2. The provider does exist. Its called openCryptoki. > > 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. Having both pkcs11-helper and a pure pkcs11 interface is not competing with one another. Obviously there are use cases for both. Kent > 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. > -- Kent Yoder IBM LTC Security Dev. ------------------------------------------------------------------------- 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
