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
