[RFC] cryptodev: asymmetric crypto random number source

[RFC] cryptodev: asymmetric crypto random number source

[Kusztal, ArkadiuszX]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

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.

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.

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)




[-- Attachment #2: Type: text/html, Size: 6854 bytes --]

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

[Akhil Goyal]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

++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.

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.

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)




[-- Attachment #2: Type: text/html, Size: 9006 bytes --]

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

[Ramkumar Balu]

> ++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.

> >
> > 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

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

[Kusztal, ArkadiuszX]

> -----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
>