Hi Arek,

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.

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