cryptodev: clarify wireless inputs in digest-encrypted cases

Message ID 1571744076-7623-1-git-send-email-fiona.trahe@intel.com (mailing list archive)
State Superseded, archived
Delegated to: akhil goyal
Headers
Series cryptodev: clarify wireless inputs in digest-encrypted cases |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/iol-intel-Performance success Performance Testing PASS
ci/Intel-compilation success Compilation OK
ci/iol-compilation success Compile Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/travis-robot success Travis build: passed

Commit Message

Fiona Trahe Oct. 22, 2019, 11:34 a.m. UTC
  Clarify constraints on fields specified in bits for wireless
algorithms in digest-encrypted case.

Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
---
 lib/librte_cryptodev/rte_crypto_sym.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
  

Comments

Akhil Goyal Oct. 22, 2019, 11:48 a.m. UTC | #1
Hi Fiona,

> 
> Clarify constraints on fields specified in bits for wireless
> algorithms in digest-encrypted case.
> 
> Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> ---
>  lib/librte_cryptodev/rte_crypto_sym.h |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> b/lib/librte_cryptodev/rte_crypto_sym.h
> index bc8da24..0204d37 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -703,6 +703,13 @@ struct rte_crypto_sym_op {
>  					 * auth.data.length and is typically
>  					 * equal to auth.data.offset +
>  					 * auth.data.length + digest_length.
> +					 * - for wireless algorithms, i.e.
> +					 * SNOW 3G, KASUMI and ZUC, as the
> +					 * cipher.data.length,
> +					 * cipher.data.offset,
> +					 * auth.data.length and
> +					 * auth.data.offset are in bits, they
> +					 * must be 8-bit multiples.

What is the meaning of 'they' here? 
cipher.data.length, cipher.data.offset, auth.data.length and auth.data.offset are in bits
and may or may not be multiple of 8bits. This is documented in their comments.


>  					 *
>  					 * Note, that for security reasons, it
>  					 * is PMDs' responsibility to not
> --
> 1.7.0.7
  
Fiona Trahe Oct. 22, 2019, noon UTC | #2
Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Tuesday, October 22, 2019 12:49 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org
> Cc: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Dybkowski, AdamX
> <adamx.dybkowski@intel.com>
> Subject: RE: [PATCH] cryptodev: clarify wireless inputs in digest-encrypted cases
> 
> Hi Fiona,
> 
> >
> > Clarify constraints on fields specified in bits for wireless
> > algorithms in digest-encrypted case.
> >
> > Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> > ---
> >  lib/librte_cryptodev/rte_crypto_sym.h |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > b/lib/librte_cryptodev/rte_crypto_sym.h
> > index bc8da24..0204d37 100644
> > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > @@ -703,6 +703,13 @@ struct rte_crypto_sym_op {
> >  					 * auth.data.length and is typically
> >  					 * equal to auth.data.offset +
> >  					 * auth.data.length + digest_length.
> > +					 * - for wireless algorithms, i.e.
> > +					 * SNOW 3G, KASUMI and ZUC, as the
> > +					 * cipher.data.length,
> > +					 * cipher.data.offset,
> > +					 * auth.data.length and
> > +					 * auth.data.offset are in bits, they
> > +					 * must be 8-bit multiples.
> 
> What is the meaning of 'they' here?
> cipher.data.length, cipher.data.offset, auth.data.length and auth.data.offset are in bits
> and may or may not be multiple of 8bits. This is documented in their comments.
> 
[Fiona] This added note is an extra bullet under the explanation for Digest-encrypted cases.
In these cases only those fields listed MUST be 8-bit multiples.
Can you suggest a change that would make that clearer?

 
> 
> >  					 *
> >  					 * Note, that for security reasons, it
> >  					 * is PMDs' responsibility to not
> > --
> > 1.7.0.7
  
Akhil Goyal Oct. 22, 2019, 12:08 p.m. UTC | #3
> 
> Hi Akhil,
> 
> >
> > Hi Fiona,
> >
> > >
> > > Clarify constraints on fields specified in bits for wireless
> > > algorithms in digest-encrypted case.
> > >
> > > Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> > > ---
> > >  lib/librte_cryptodev/rte_crypto_sym.h |    7 +++++++
> > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > > b/lib/librte_cryptodev/rte_crypto_sym.h
> > > index bc8da24..0204d37 100644
> > > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > > @@ -703,6 +703,13 @@ struct rte_crypto_sym_op {
> > >  					 * auth.data.length and is typically
> > >  					 * equal to auth.data.offset +
> > >  					 * auth.data.length + digest_length.
> > > +					 * - for wireless algorithms, i.e.
> > > +					 * SNOW 3G, KASUMI and ZUC, as the
> > > +					 * cipher.data.length,
> > > +					 * cipher.data.offset,
> > > +					 * auth.data.length and
> > > +					 * auth.data.offset are in bits, they
> > > +					 * must be 8-bit multiples.
> >
> > What is the meaning of 'they' here?
> > cipher.data.length, cipher.data.offset, auth.data.length and auth.data.offset
> are in bits
> > and may or may not be multiple of 8bits. This is documented in their comments.
> >
> [Fiona] This added note is an extra bullet under the explanation for Digest-
> encrypted cases.
> In these cases only those fields listed MUST be 8-bit multiples.
> Can you suggest a change that would make that clearer?

@@ -590,7 +590,9 @@ struct rte_crypto_sym_op {
                                          * For SNOW 3G @ RTE_CRYPTO_CIPHER_SNOW3G_UEA2,
                                          * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
                                          * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
-                                         * this field should be in bits.
+                                         * this field should be in bits and must be
+                                         * 8-bit multiples in cases of encrypted
+                                         * digest.
                                          */

Same change may be done in other 3 fields.

> 
> 
> >
> > >  					 *
> > >  					 * Note, that for security reasons, it
> > >  					 * is PMDs' responsibility to not
> > > --
> > > 1.7.0.7
  
Fiona Trahe Oct. 22, 2019, 12:32 p.m. UTC | #4
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Tuesday, October 22, 2019 1:08 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org
> Cc: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Dybkowski, AdamX
> <adamx.dybkowski@intel.com>
> Subject: RE: [PATCH] cryptodev: clarify wireless inputs in digest-encrypted cases
> 
> 
> 

> @@ -590,7 +590,9 @@ struct rte_crypto_sym_op {
>                                           * For SNOW 3G @ RTE_CRYPTO_CIPHER_SNOW3G_UEA2,
>                                           * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
>                                           * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
> -                                         * this field should be in bits.
> +                                         * this field should be in bits and must be
> +                                         * 8-bit multiples in cases of encrypted
> +                                         * digest.
>                                           */
> 
> Same change may be done in other 3 fields.
Ok, thanks, I'll send v2
  

Patch

diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index bc8da24..0204d37 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -703,6 +703,13 @@  struct rte_crypto_sym_op {
 					 * auth.data.length and is typically
 					 * equal to auth.data.offset +
 					 * auth.data.length + digest_length.
+					 * - for wireless algorithms, i.e.
+					 * SNOW 3G, KASUMI and ZUC, as the
+					 * cipher.data.length,
+					 * cipher.data.offset,
+					 * auth.data.length and
+					 * auth.data.offset are in bits, they
+					 * must be 8-bit multiples.
 					 *
 					 * Note, that for security reasons, it
 					 * is PMDs' responsibility to not