Re: Proposal for adding setpubkey callback to akcipher_alg

[Stephan Mueller <smueller@chronox.de>]

Am Montag, 3. August 2015, 00:03:03 schrieb Marcel Holtmann:

Hi Marcel,

> Hi Stephan,
> 
> >> 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
> > 
> > The public key is n + e.
> > 
> > The private key is n + d.
> 
> for RSA Public Key it is just n and e. However for RSA Private Key it is n
> and e and d and also version, primes etc. So the RSA Public Key contains a
> sequence of 2 integers and the RSA Private Key contains a sequence of 9
> integers.
> > Both are encoded in the BER structure the current API requires. It is
> > perfectly valid to provide only n + e when you do public key operations.
> 
> And from an API perspective that is fully wrong from my point of view. We
> just invented another format that is not in any standard. The two standard
> key formats for RSA are RSA Private Key and RSA Public Key. These are the
> ones we should support.
> 
> The format with n plus e and optionally d is total Linux invention as far as
> I can tell. And I do not want this exposed to userspace.
> 
> For a clean separation I think splitting this into setkey for the RSA
> Private Key and setpubkey for the RSA Public Key is pretty obvious choice.

Please define exactly what your pubkey and your privkey contains. Even when I 
think of the DER keys from OpenSSL, we once have n+e and once n+e+d (see 
asn1dump), no?


> > Please see in the testmgr.h for the 2048 bit key test vector (i.e. the one
> > with public_key_vec = true). The BER structure has nice comments from
> > Tadeusz to indicate it only contains n and e without d.
> 
> And it is totally made up format. Why would you force conversion of a RSA

BER is a made up implementation? I do not think so: 
https://en.wikipedia.org/wiki/Basic_Encoding_Rules

Or do you say that the kernel's implementation of BER is broken?

> Public Key or RSA Private Key in DER format into this format. This Linux
> only input format makes it just complicated for no reason. It is also not
> documented anywhere as I can tell. I had to dig this out of the code and
> rsakey.asn1.
> 
> As mentioned above, splitting this into two functions makes this simpler.
> For all intense and purposes this is akcipher so we always either have
> public/private key pair or we just have the public key. And at least with
> RSA they are defined as two independent formats.

I can see that user space (e.g. libkcapi) has such two functions. But 
currently I do not see such distinction necessary in the kernel as mentioned 
above.
> 
> Since the parsing of the key data is not a generic handling, I do not see a
> good enough reason to invent new formats. Use the format the cipher you
> implement already has defined.
> > Thus, I do not currently understand your request. May I ask you to give
> > more explanation why the use of BER is insufficient?
> 
> Tell me how you create this Linux specific BER encoded key. I would like
> someone to provide the magic OpenSSL conversion command line to get this.

Again: there is no DER to BER converter that I am aware of. Agreed, that 
should be there. But currently I do not see that the kernel should do that.

> Hand crafting such keys when there is a standard format for RSA Private Key
> and RSA Public Key makes no sense whatsoever.

Fully agreed. Thus, a BER encoder is on my agenda for libkcapi.

-- 
Ciao
Stephan