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