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
--
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
