> > > - 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.kusz...@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.
