> -----Original Message----- > From: Ramkumar Balu <rb...@marvell.com> > Sent: Monday, December 13, 2021 10:27 AM > To: Akhil Goyal <gak...@marvell.com>; Kusztal, ArkadiuszX > <arkadiuszx.kusz...@intel.com>; Anoob Joseph <ano...@marvell.com>; Zhang, > Roy Fan <roy.fan.zh...@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 >
