> > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > b/lib/cryptodev/rte_crypto_asym.h index 97c3fbee38..c864b8a115 100644
> > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > @@ -205,12 +205,29 @@ struct rte_crypto_rsa_priv_key_qt {
> > >   */
> > >  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;
> >
> > Any specific reason to change the field name?
> > I think this matches with the next field mgf1md
> [Arek] - now it aligns with RSA RFC. Both current names comes from the
> OpenSSL EVP_MD naming, in my rfc initially mgf1md was changed too into:
> +enum rte_crypto_mgf {
> +     RTE_CRYPTO_MGF_DEFAULT,
> +     /**< Default mask generation function */
> +     RTE_CRYPTO_MGF_MGF1_SHA1,
> +     /**< MGF1 function with SHA1 hash algorithm */
> But we do not need to be that conformant with the standard I think, so I have
> left it out.
> As for names it may be 'md' as well, every name is ok if is not excessively 
> long.
> 
No strong opinion, you can keep any of them.

> >
> > > - /**< Hash algorithm to be used for data hash if padding
> > > -  * scheme is either OAEP or PSS. Valid hash algorithms
> > > -  * are:
> > > -  * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
> > > + /**< Type of RSA padding */
> > > + enum rte_crypto_auth_algorithm hash;
> > > + /**<
> > > +  * 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)
> > >    */
> > >   enum rte_crypto_auth_algorithm mgf1md;
> > >   /**<
> > > @@ -220,6 +237,21 @@ struct rte_crypto_rsa_padding {
> > >    * for mask generation. Valid hash algorithms are:
> > >    * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
> > >    */
> > > + uint16_t saltlen;
> > > + /**<
> > > +  * RSA PSS padding salt length
> > > +  *
> > > +  * Used only when RTE_CRYPTO_RSA_PADDING_PSS padding is
> > > selected,
> >
> > Used only when RTE_CRYPTO_RSA_PADDING_PSS is selected,
> >
> > > +  * otherwise ignored.
> > > +  */
> > > + rte_crypto_param label;
> > > + /**<
> > > +  * RSA OAEP padding optional label
> > > +  *
> > > +  * Used only when RTE_CRYPTO_RSA_PADDING_OAEP padding is
> > > selected,
> >
> > Drop the word padding.
> >
> > BTW, can this be a union for label and saltlen?
> Yes, will do.
> > Also can we name them as pss_saltlen and oaep_label?
> Yes, though I am not entirely convinced. These names are unique anyway.
I believe it will improve readability.

> >
> > > +  * otherwise ignored. If label.data == NULL, a default
> > > +  * label (empty string) is used.
> > > +  */
> > >  };
> > >
> > >  /**
> > > --
> > > 2.13.6

Reply via email to