On 08/03/2015 10:39 AM, Marcel Holtmann wrote: > I already have patches for that actually. The question is just which approach > to take? > > My current proposal is to separate the current crypto_akcipher_setkey into > two functions. Use the crypto_akcipher_setkey for loading combined private > and public key formats and crypto_akcipher_setpubkey for just loading the > public key only format.
I would prefer to have one setkey function if possible. > > One other option is actually for crypto_akcipher_setkey to use struct > public_key from include/crypto/public_key.h. I mean we have this all defined. > Why do we operate on binary blobs for the keys in the first place. For > example if the key comes from a certificate in the keyring, lets just use > that data. Most likely the asymmetric key type already decoded it nicely for > us. No need to do this again. That was the first proposal to use this struct, but it was rejected. Looks like MPIs are not acceptable on the API. I think it make sense now as it will only be useful for the SW implementation. For hardware the easiest way is to take it in this form. > > I mean there is more than RSA out there and this would allow us to express > struct public_key_algorithm in addition to the allowed applications of said > key as well. This would properly also allow us to combine the > crypto/asymmetric_keys/rsa.c and crypto/rsa.c so that we only have a single > RSA implementation. Not to mention that we also have lib/digsig.c in the > kernel. The crypto/asymmetric_keys/ will be converted to the new api and crypto/asymmetric_keys/rsa.c removed soon. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
