[EXT] [PATCH 38/40] cryptodev: clarify usage of private key in dh

[Akhil Goyal]

> > > - clarified usage of private key in Diffie-Hellman.
> > > CSRNG capable device should generate private key and then use it for
> > > public key generation.
> > >
> > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal at intel.com>
> > > ---
> > >  lib/cryptodev/rte_crypto_asym.h | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > b/lib/cryptodev/rte_crypto_asym.h index 01b1fdd074..a6bb70ca3f 100644
> > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > @@ -459,6 +459,10 @@ struct rte_crypto_dh_op_param {
> > >  	 * Output generated private key when op_type is
> > >  	 * DH PRIVATE_KEY_GENERATION
> > >  	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > +	 * In case priv_key.length is 0 and op_type is set with
> > > +	 * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE, CSRNG capable
> > > +	 * device will generate private key and use it for public
> > > +	 * key generation.
> >
> > What is expected for the device which does not support this?
> > How will the application decide?
> [Arek] - it is similar issue as in DSA/ECDSA 'k'. Or we will add some PMD flag to
> determine if PMD is CSRNG capable or it will be stated in PMD .rst file. If device
> does not support random, packet will be rejected (send to response queue with
> NOT_PROCESSED). This comment should probably be added.

I believe this can be covered in the capability patch that you are working on.