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

Kusztal, ArkadiuszX arkadiuszx.kusztal at intel.com
Mon Aug 30 17:49:06 CEST 2021



> -----Original Message-----
> From: dev <dev-bounces at dpdk.org> On Behalf Of Akhil Goyal
> Sent: Saturday, July 31, 2021 8:13 PM
> To: dev at dpdk.org
> Cc: thomas at monjalon.net; david.marchand at redhat.com;
> hemant.agrawal at nxp.com; anoobj at marvell.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch at intel.com>; Trahe, Fiona <fiona.trahe at intel.com>;
> Doherty, Declan <declan.doherty at intel.com>; matan at nvidia.com;
> g.singh at nxp.com; Zhang, Roy Fan <roy.fan.zhang at intel.com>;
> jianjay.zhou at huawei.com; asomalap at amd.com; ruifeng.wang at arm.com;
> Akhil Goyal <gakhil at 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


More information about the dev mailing list