> 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
