cryptodev: clarify wireless inputs in digest-encrypted cases
Checks
Commit Message
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
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
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
>
> 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
> -----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
@@ -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