Hi Tadeusz,
I think we need to split the akcipher_alg setkey callback into a setkey and
setpubkey.
diff --git a/include/crypto/akcipher.h b/include/crypto/akcipher.h
index 69d163e39101..ca93952b6d19 100644
--- a/include/crypto/akcipher.h
+++ b/include/crypto/akcipher.h
@@ -91,6 +91,8 @@ struct akcipher_alg {
int (*decrypt)(struct akcipher_request *req);
int (*setkey)(struct crypto_akcipher *tfm, const void *key,
unsigned int keylen);
+ int (*setpubkey)(struct crypto_akcipher *tfm, const void *key,
+ unsigned int keylen);
int (*init)(struct crypto_akcipher *tfm);
void (*exit)(struct crypto_akcipher *tfm);
If the cipher actually uses two different formats for the public + private key
data compared to just the public key data, then it is useful to have these
independent. That way we can use standard formats for the keys and do not have
to have a Linux kernel specific key format.
My definition would be that setkey sets the private and public key. And the
setpubkey only sets the public key. So depending on which format of keys you
have, you call the proper function and it will do the rest for you. At least
for RSA this solves the problem that I described in my previous email and we
could use RSA standard ASN.1 formats for each of the key files.
For obvious reasons, when you only call setpubkey, then only encrypt and verify
will work. However if you call setkey, then you can sign, verify, encrypt and
decrypt.
When exposing akcipher via AF_ALG, I would also propose to add a ALG_SET_PUBKEY
so that userspace can clearly tell the kernel which part of the keys it has.
This would map nicely and we then know which ASN.1 decoder to call instead of
having to guess what format userspace provided. In case of RSA, the user
already selected RSA as cipher. So it either has RSA Public Key and would use
ALG_SET_PUBKEY or it has RSA Private Key and would use ALG_SET_KEY. Since the
key formats do not describe themselves, I think this is the cleaner solution
from an API point of view.
On a side note, that the ASN.1 decoder accepts a key with two integers even
while the format describes three integers seems like a bug in the decoder and
not a feature. If the third integer is not marked as optional, the decoder
should just fail the parsing.
Regards
Marcel
--
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
