Hi Adam, Anoob,
> > > >
> > > > > -----Original Message-----
> > > > > From: dev <dev-boun...@dpdk.org> On Behalf Of Adam Dybkowski
> > > > > Sent: Monday, May 18, 2020 7:54 PM
> > > > > To: dev@dpdk.org; fiona.tr...@intel.com; akhil.go...@nxp.com
> > > > > Cc: Adam Dybkowski <adamx.dybkow...@intel.com>; sta...@dpdk.org
> > > > > Subject: [dpdk-dev] [PATCH] cryptodev: fix SHA-1 digest enum
> > > > > comment
> > > > >
> > > > > This patch fixes improper SHA-1 digest size in the enum comment.
> > > > >
> > > > > Fixes: 1bd407fac80b ("cryptodev: extract symmetric operations")
> > > > > Cc: sta...@dpdk.org
> > > > >
> > > > > Signed-off-by: Adam Dybkowski <adamx.dybkow...@intel.com>
> > > > > ---
> > > > > lib/librte_cryptodev/rte_crypto_sym.h | 4 ++--
> > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > > > > b/lib/librte_cryptodev/rte_crypto_sym.h
> > > > > index d9585ecd6..9cea4e5f0 100644
> > > > > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > > > > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > > > > @@ -269,9 +269,9 @@ enum rte_crypto_auth_algorithm {
> > > > > /**< HMAC using MD5 algorithm */
> > > > >
> > > > > RTE_CRYPTO_AUTH_SHA1,
> > > > > - /**< 128 bit SHA algorithm. */
> > > > > + /**< 160 bit SHA algorithm. */
> > > > > RTE_CRYPTO_AUTH_SHA1_HMAC,
> > > > > - /**< HMAC using 128 bit SHA algorithm. */
> > > > > + /**< HMAC using 160 bit SHA algorithm. */
> > > >
> > > > [Anoob] This raises one interesting question. Is HMAC-SHA-1-96
> > > > (https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org
> > > > _h
> > > >
> > >
> > tml_rfc2404&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8rwwviRSxyL
> > Ws2
> > > n6B-
> > >
> > WYLn1v9SyTMrT5EQqh2TU&m=pgqB2BfFosCF_7l1SdoodgXcipf7G1ofht68ZK
> > Mt
> > > oW0&s=hxzUN2QfRJGaR7NQ7VKGm5oQvOZez6Z70mqOyg7gKTY&e= )
> > treated as a
> > > separate algorithm or is it a digest size variant of
> > > RTE_CRYPTO_AUTH_SHA1_HMAC? I assume the later.
> > >
> > > [Adam] DPDK doesn't have separate enums for such variations. According
> > > to RFC 2104, chapter "5. Truncated output", the calculation of
> > > HMAC-SHA-1-96 is done using ordinary HMAC-SHA-1, but the calculation
> > > result is then truncated to 96 bits, or any other digest size provided in
> > > auth
> > xform.
> >
> > [Anoob] So it is allowed to support digest sizes 12 & 20, right? Can you
> > update the above comment in that case?
>
> [Adam] This depends on a particular PMD and its capabilities so we cannot
> write here in this public
> header file. For example, have a look in the capabilities structure of QAT
> PMD:
>
> { /* SHA1 */ \
> .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, \
> {.sym = { \
> .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH, \
> {.auth = { \
> .algo = RTE_CRYPTO_AUTH_SHA1, \
> .block_size = 64, \
> .key_size = { \
> .min = 0, \
> .max = 0, \
> .increment = 0 \
> }, \
> .digest_size = { \
> .min = 1, \
> .max = 20, \
> .increment = 1 \
> }, \
> .iv_size = { 0 } \
> }, } \
> }, } \
> }, \
>
> It shows QAT PMD is able to truncate the output digest to any size from 1 to
> 20 bytes (160 bits).
>
> This can be different in other PMDs, for example OpenSSL and CCP PMDs allow
> only 20-byte digests
> here while Marvell MVSAM allows 12-20 bytes.
>
> Adam
[Fiona] True. But as 96 bits is a standard variant described in the spec, how
about adding
/**< HMAC using 160 bit SHA algorithm.
HMAC-SHA-1-96 can be generated by setting digest_size to 12 */
This doesn't imply that all PMDs must support that - same as for any other
feature, the capabilities can vary.
