> -----Original Message-----
> From: dev <dev-boun...@dpdk.org> On Behalf Of Akhil Goyal
> Sent: Saturday, July 31, 2021 8:13 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; david.march...@redhat.com;
> hemant.agra...@nxp.com; ano...@marvell.com; De Lara Guarch, Pablo
> <pablo.de.lara.gua...@intel.com>; Trahe, Fiona <fiona.tr...@intel.com>;
> Doherty, Declan <declan.dohe...@intel.com>; ma...@nvidia.com;
> g.si...@nxp.com; Zhang, Roy Fan <roy.fan.zh...@intel.com>;
> jianjay.z...@huawei.com; asoma...@amd.com; ruifeng.w...@arm.com;
> Akhil Goyal <gak...@marvell.com>
> Subject: [dpdk-dev] [PATCH 2/4] cryptodev: promote asym APIs to stable
>
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
