RE: [RFC] cryptodev: asymmetric crypto random number source

["Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>]

> -----Original Message-----
> From: Ramkumar Balu <rbalu@marvell.com>
> Sent: Monday, December 13, 2021 10:27 AM
> To: Akhil Goyal <gakhil@marvell.com>; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>; Anoob Joseph <anoobj@marvell.com>; Zhang,
> Roy Fan <roy.fan.zhang@intel.com>
> Cc: dev@dpdk.org
> Subject: RE: [RFC] cryptodev: asymmetric crypto random number source
> 
> > ++Ram for openssl
> >
> > > ECDSA op:
> > >        rte_crypto_param k;
> > >               /**< The ECDSA per-message secret number, which is an
> > >integer
> > >               * in the interval (1, n-1)
> > >               */
> > > DSA op:
> > >               No 'k'.
> > >
> > > This one I think have described some time ago:
> > > Only PMD that verifies ECDSA is OCTEON which apparently needs 'k' provided
> by user.
> > > Only PMD that verifies DSA is OpenSSL PMD which will generate its own
> random number internally.
> > >
> > > So in case PMD supports one of these options (or especially when supports
> both) we need to give some information here.
> 
> We can have a standard way to represent if a particular rte_crypto_param is set
> by the application or not.  Then, it is up to the PMD to perform the op or return
> error code if unable to proceed.
> 
> > >
> > > The most obvious option would be to change rte_crypto_param k ->
> > > rte_crypto_param *k In case (k == NULL) PMD should generate it itself if
> possible, otherwise it should push crypto_op to the response ring with
> appropriate error code.
> 
> This case could occur for other params as well. Having a few as nested variables
> and others as pointers could be confusing for memory alloc/dealloc. However,
> the rte_crypto_param already has a data pointer inside it which can be used in
> same manner. For example, in this case (k.data == NULL), PMD should generate
> random number if possible or push to response ring with error code. This can be
> done without breaking backward compatibility.
> This can be the standard way for PMDs to find if a particular rte_crypto_param is
> valid or NULL.
[Arek] Agree, let keep it as easy as possible, and agree it could be useful elsewhere not necessarily  in random number cases.

> 
> > >
> > > Another options would be:
> > > - Extend rte_cryptodev_config and rte_cryptodev_info with
> > > information about random number generator for specific device
> > > (though it would be ABI breakage)
> > > - Provide some kind of callback to get random number from user
> > > (which could be useful for other things like RSA padding as well)
> 
> I think the previous solution itself is more straightforward and simpler unless we
> want to have functionality to configure random number generator for each
> device.
> 
> Thanks,
> Ramkumar Balu
>