> -----Original Message-----
> From: Akhil Goyal <gak...@marvell.com>
> Sent: Thursday, May 26, 2022 2:20 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>; dev@dpdk.org
> Cc: Zhang, Roy Fan <roy.fan.zh...@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?
