Re: [dpdk-dev] [PATCH 2/4] cryptodev: promote asym APIs to stable

["Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>]

> Do you think all the asym APIs are not eligible for promoting it to stable APIs?
> I haven't seen any changes for quite some time and we cannot have it
> experimental Forever.
> The APIs which you think are expected to change, we can leave them as
> experimental And mark the others as stable.
We could potentially make capability related functions stable but for others there are still some many uncertainties, another example:
Ecdsa op expects 'k' in "in the interval (1, n-1)", openssl pmd will not even have function that accepts 'k' (although optionally inverse of k yes), what should user put then here?

This API needs more attention I believe, I can send patches for it after 21.11 release. 
My opinion is that we should push all this by another year.

> 
> Can you post a patch for it? I will drop it from my series.
> 
> Also, could you review the other patches in the series as well.
> 
> Regards,
> Akhil
> 
> > Hi Akhil,
> >
> > I am not sure if this API is ready to be stable so I will add few comments here:
> >
> > RSA:
> > 	rte_crypto_param message;
> > 	...
> > 	 * - to be signed for RSA sign generation.
> >
> > If this message is plaintext, then in case of:
> > 1) PKCS1_1.5 padding:
> > Standard defines data to be signed as DER encoded struct of
> > digestAlgorithm
> > + digest
> > (few exceptions I am aware of were TLS prior to 1.2 or IKE version 1)
> > - There is no field to specify that, even if PMD would be correctly
> > implemented it still would lack information about hash aglorithm.
> > - Currently what openssl pmd for example is doing is
> > RSA_private_encrypt which omits this step
> (https://www.openssl.org/docs/man1.1.1/man3/RSA_private_encrypt.html  -
> mentions this).
> > 2) PADDING_NONE:
> > I cannot find what user is supposed to do in this case, and I think it
> > may be quite common option for hw due to reliance on strong CSPRNG for
> > PSS or OAEP.
> >
> > DSA:
> > 	struct rte_crypto_dsa_op_param {
> > 	...
> > There is no 'k' parameter? I though I have added it, how hw with no
> > CSRNG should work with DSA?
> >
> > For ECDSA private key is in Op, for DSA is in xform. Where this
> > inconsistency comes from?
> >
> > 	/**< x: Private key of the signer in octet-string network
> > 	 * byte order format.
> > 	 * Used when app has pre-defined private key.
> > 	 * Valid only when xform chain is DSA ONLY.
> > 	 * if xform chain is DH private key generate + DSA, then DSA sign
> > 	 * compute will use internally generated key.
> >
> > And this one I cannot understand, there is DH and DSA in one line plus
> > seems that private dsa key would be generated and used in the same
> operation.
> > We want to create self-signed certificate here on the fly or something?
> >
> > 	RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
> > 	/**< DH Private Key generation operation */
> >
> > This is another interesting part (similar to 'k' in (EC)DSA, PSS, QAEO
> > in RSA), there was no any type of hw random number generation concept
> > for symmetric crypto (i.e. salt, IV, nonce) and here we have
> > standalone Diffie Hellman private key generator.
> > And since it is no crypto computation but random number generation,
> > maybe there should be another module to handle CSRNG or we could
> > register randomness source into cryptodev, like callback? Another
> > option would be to predefine randomness source per device like (i.e.
> > x86 RDRAND, /dev/random) for user to decide.
> >
> > Additionally there is DH op but there is no ECDH (I know there is
> > ECPM, but the same way there is MODEXP which creates another
> inconsistency).
> > Optionally we can extend DH API to work with EC?
> > EDDSA, EDDH needs to be implemented soon too.
> >
> > Regards,
> > Arek