[EXT] [PATCH v2 11/14] cryptodev: move RSA padding into separate struct

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil at marvell.com>
> Sent: Thursday, May 26, 2022 2:20 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal at intel.com>; dev at dpdk.org
> Cc: Zhang, Roy Fan <roy.fan.zhang at intel.com>
> Subject: RE: [EXT] [PATCH v2 11/14] cryptodev: move RSA padding into separate
> struct
> 
> > > >  /**
> > > > + * RSA padding type
> > > > + */
> > > > +struct rte_crypto_rsa_padding {
> > > > +	enum rte_crypto_rsa_padding_type type;
> > > > +	/**< RSA padding scheme to be used for transform */
> > > > +	enum rte_crypto_auth_algorithm md;
> > > > +	/**<
> > > > +	 * RSA padding hash function
> > > > +	 *
> > > > +	 * When a specific padding type is selected, the following rule apply:
> > > > +	 * - RTE_CRYPTO_RSA_PADDING_NONE:
> > > > +	 * This field is ignored by the PMD
> > > > +	 *
> > > > +	 * - RTE_CRYPTO_RSA_PADDING_PKCS1_5:
> > > > +	 * When signing operation this field is used to determine value
> > > > +	 * of the DigestInfo structure, therefore specifying which algorithm
> > > > +	 * was used to create the message digest.
> > > > +	 * When doing encryption/decryption this field is ignored for this
> > > > +	 * padding type.
> > > > +	 *
> > > > +	 * - RTE_CRYPTO_RSA_PADDING_OAEP
> > > > +	 * This field shall be set with the hash algorithm used
> > > > +	 * in the padding scheme
> > > > +	 *
> > > > +	 * - RTE_CRYPTO_RSA_PADDING_PSS
> > > > +	 * This field shall be set with the hash algorithm used
> > > > +	 * in the padding scheme (and to create the input message digest)
> > > > +	 */
> > > Forgot to comment on previous patch about the valid algos for this.
> > > They are removed in previous patch, but it should not be removed. Right?
> > Which hash functions are supported by RSA can be found in RSA
> > standard, additionally our list was incomplete.
> > There is no Hash functions enum in Cryptodev -> we keep Hash functions
> > together with mac aglorithms, so that's why it was probably included
> > in the first place. But I would say we should not specify valid algs here.
> 
> In that case, mgf1md comment should also be updated.
> But again, if we are combining with mac algos, we should specify it. Right? This
> is not RFC, it is our implementation of the RFC. If we are combining with mac
> algos, it makes more sense to specify the valid algos.
Its actually not that big problem, though I thought it is stating the obvious.
So we can add it back again but with full RSA hash list (including 512/224 256), or we will add it when this will be added to rte_crypto_auth_algorithm?