Hi Marcel, On 03/07/2016 02:29 PM, Marcel Holtmann wrote: >> In this way we can define a generic user side of the key exchange interface, >> > and on the the driver side of the akcipher, the implementations would overload >> > the existing akcipher encrypt(), decrypt(), set_pub_key(), set_priv_key() methods >> > and do what should be done for a given algorithm. We just need to agree on the >> > format of the input parameters to these operations. > I think trying to heavily map this to encrypt and decrypt is a bad idea. These callbacks are not really designed to return what you need them to return. Key exchange is different. > > So why are we trying to push this into akcipher in the first place? I mean lets just create a keyexch (or similar name) and design it explicitly for key exchange handling. We are also not trying to map hashes into skcipher. I think the clear distinction of semantics calls for a different API. > I just think that before introducing new API we should try to reuse what's already there. Looking at RSA and DH, they basically perform x = a^b mod p, so we should have what's needed for both and we just could overload the methods already defined. I'm fine either way. Herbert, what's your preference? >> Agree, we need to support all the cases, but dealing with different type of keys >> > needs to happen above this API. This API should solely be an interface to math >> > primitives of certain operations, which can be implemented in SW or can be HW >> > accelerated. Modules like public_key or afalg_akcipher need to be smart enough >> > and know what key types they deal with and do the right thing depending on that >> > knowledge. > I am not sure this can be that easily generalized. Just pushing the problem of key types and formats off to userspace just forces complexity and extra knowledge there. We need to be really carefully here. And I really dislike introducing custom ASN.1 structures that are not backed by an actual RFC document. I'm not saying that we should push this to user space. I'm just saying this should be handled above the crypto API. >> Agree, and to make this work with afalg_akcipher, I have proposed new >> > ALG_SET_KEY_ID and ALG_SET_KEY_ID operations. See here: https://lkml.org/lkml/2015/12/26/65 >> > The plan is that in this case the afalg_akcipher will not use akcipher api at all. >> > In this case the algif_akcipher will use the request_key() interface to retrieve >> > the key type info and will use the operations that the new TPM interface will define. > The ALG_SET_KEY_ID is great for skcipher where you key is a fixed size blob. There is works really well. And you will need if we let keyctl derive the session key from a set of asymmetric keys. > > I get that we want to enable OpenSSL and others to gain access to kernel crypto operations. We want the same actually for ELL as well. However what is dangerous here is that AF_ALG can never support hardware based keys. So that means support in OpenSSL is broken by design. See earlier emails from David Woodhouse. If you have your certificates / keys in hardware then you need to be able to make them work with OpenSSL. We can not ignore this. It is a design we need to consider from the beginning. If we will have the TPM interface that allows to invoke functions for HW keys and the *_KEY_ID, then I don't see why AF_ALG would not work. As I said, in case when the keys will be in HW the algif_akcipher will not use akcipher api, but use the TPM defined functions in the same way as the keyctl would use it. So I think both AF_ALG and keyctl should work just fine. Thanks, -- TS -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
