cryptodev: add an option to support both iv and J0 for GCM
Checks
Commit Message
This patch adds an option to support both IV (of all supported sizes)
and J0 when using Galois Counter Mode of crypto operation.
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
1 file changed, 19 insertions(+), 18 deletions(-)
Comments
Hi Arek,
> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, April 17, 2019 8:37 AM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH] cryptodev: add an option to support both iv and J0 for GCM
>
> This patch adds an option to support both IV (of all supported sizes)
> and J0 when using Galois Counter Mode of crypto operation.
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
> index c80e90e..126d9f3 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -152,11 +152,6 @@ struct rte_crypto_cipher_xform {
> *
> * - For block ciphers in CTR mode, this is the counter.
> *
> - * - For GCM mode, this is either the IV (if the length
> - * is 96 bits) or J0 (for other sizes), where J0 is as
> - * defined by NIST SP800-38D. Regardless of the IV
> - * length, a full 16 bytes needs to be allocated.
> - *
> * - For CCM mode, the first byte is reserved, and the
> * nonce should be written starting at &iv[1] (to allow
> * space for the implementation to write in the flags
> @@ -184,9 +179,6 @@ struct rte_crypto_cipher_xform {
> * of the counter (which must be the same as the block
> * length of the cipher).
> *
> - * - For GCM mode, this is either 12 (for 96-bit IVs)
> - * or 16, in which case data points to J0.
> - *
> * - For CCM mode, this is the length of the nonce,
> * which can be in the range 7 to 13 inclusive.
> */
> @@ -306,9 +298,10 @@ struct rte_crypto_auth_xform {
> * specified as number of bytes from start of crypto
> * operation (rte_crypto_op).
> *
> - * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
> - * for AES-GMAC, this is the authentication
> - * Initialisation Vector (IV) value.
> + * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
> + * this is the authentication Initialisation Vector
> + * (IV) value. For AES-GMAC IV description please refer
> + * to the field `length` in iv struct.
> *
> * - For KASUMI in F9 mode and other authentication
> * algorithms, this field is not used.
> @@ -325,6 +318,14 @@ struct rte_crypto_auth_xform {
> * - For KASUMI in F9 mode and other authentication
> * algorithms, this field is not used.
> *
> + * - For GMAC mode, this is either:
> + * 1) Number greater or equal to one, which means that IV
> + * is used and J0 will be computed internally, 16 bytes
> + * needs to be allocated.
[Fiona] IVs greater than 16 bytes can be used, right? If so change
to "a minimum of 16 bytes must be allocated". Same below.
> + * 2) Zero, in which case data points to J0. In this case
> + * 16 bytes of J0 should be passed where J0 is defined
> + * by NIST SP800-38D.
> + *
> */
> } iv; /**< Initialisation vector parameters */
>
> @@ -383,11 +384,6 @@ struct rte_crypto_aead_xform {
> * specified as number of bytes from start of crypto
> * operation (rte_crypto_op).
> *
> - * - For GCM mode, this is either the IV (if the length
> - * is 96 bits) or J0 (for other sizes), where J0 is as
> - * defined by NIST SP800-38D. Regardless of the IV
> - * length, a full 16 bytes needs to be allocated.
> - *
> * - For CCM mode, the first byte is reserved, and the
> * nonce should be written starting at &iv[1] (to allow
> * space for the implementation to write in the flags
> @@ -401,8 +397,13 @@ struct rte_crypto_aead_xform {
> uint16_t length;
> /**< Length of valid IV data.
> *
> - * - For GCM mode, this is either 12 (for 96-bit IVs)
> - * or 16, in which case data points to J0.
> + * - For GCM mode, this is either:
> + * 1) Number greater or equal to one, which means that IV
> + * is used and J0 will be computed internally, 16 bytes
> + * needs to be allocated.
> + * 2) Zero, in which case data points to J0. In this case
> + * 16 bytes of J0 should be passed where J0 is defined
> + * by NIST SP800-38D.
> *
> * - For CCM mode, this is the length of the nonce,
> * which can be in the range 7 to 13 inclusive.
> --
> 2.1.0
Hi Fiona,
> [Fiona] IVs greater than 16 bytes can be used, right? If so change to "a minimum of 16 bytes must be >allocated". Same below.
[AK] - yes, this comment may be misleading, of course it means 16 bytes minimum. This is because of legacy reasons, i.e. aesni-gcm once had formation of pre-counter block inside the PMD using the existing buffer (when len(iv)==12), hence need for 16 bytes allocation. Some other drivers still can behave in similar fashion so it probably has to stay for a while.
I will send v2.
> -----Original Message-----
> From: Trahe, Fiona
> Sent: Wednesday, April 17, 2019 1:38 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: akhil.goyal@nxp.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [PATCH] cryptodev: add an option to support both iv and J0 for
> GCM
>
> Hi Arek,
>
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX
> > Sent: Wednesday, April 17, 2019 8:37 AM
> > To: dev@dpdk.org
> > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>; De Lara
> > Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Kusztal, ArkadiuszX
> > <arkadiuszx.kusztal@intel.com>
> > Subject: [PATCH] cryptodev: add an option to support both iv and J0
> > for GCM
> >
> > This patch adds an option to support both IV (of all supported sizes)
> > and J0 when using Galois Counter Mode of crypto operation.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> > lib/librte_cryptodev/rte_crypto_sym.h | 37
> > ++++++++++++++++++-----------------
> > 1 file changed, 19 insertions(+), 18 deletions(-)
> >
> > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > b/lib/librte_cryptodev/rte_crypto_sym.h
> > index c80e90e..126d9f3 100644
> > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > @@ -152,11 +152,6 @@ struct rte_crypto_cipher_xform {
> > *
> > * - For block ciphers in CTR mode, this is the counter.
> > *
> > - * - For GCM mode, this is either the IV (if the length
> > - * is 96 bits) or J0 (for other sizes), where J0 is as
> > - * defined by NIST SP800-38D. Regardless of the IV
> > - * length, a full 16 bytes needs to be allocated.
> > - *
> > * - For CCM mode, the first byte is reserved, and the
> > * nonce should be written starting at &iv[1] (to allow
> > * space for the implementation to write in the flags @@ -
> 184,9
> > +179,6 @@ struct rte_crypto_cipher_xform {
> > * of the counter (which must be the same as the block
> > * length of the cipher).
> > *
> > - * - For GCM mode, this is either 12 (for 96-bit IVs)
> > - * or 16, in which case data points to J0.
> > - *
> > * - For CCM mode, this is the length of the nonce,
> > * which can be in the range 7 to 13 inclusive.
> > */
> > @@ -306,9 +298,10 @@ struct rte_crypto_auth_xform {
> > * specified as number of bytes from start of crypto
> > * operation (rte_crypto_op).
> > *
> > - * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
> > - * for AES-GMAC, this is the authentication
> > - * Initialisation Vector (IV) value.
> > + * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
> > + * this is the authentication Initialisation Vector
> > + * (IV) value. For AES-GMAC IV description please refer
> > + * to the field `length` in iv struct.
> > *
> > * - For KASUMI in F9 mode and other authentication
> > * algorithms, this field is not used.
> > @@ -325,6 +318,14 @@ struct rte_crypto_auth_xform {
> > * - For KASUMI in F9 mode and other authentication
> > * algorithms, this field is not used.
> > *
> > + * - For GMAC mode, this is either:
> > + * 1) Number greater or equal to one, which means that IV
> > + * is used and J0 will be computed internally, 16 bytes
> > + * needs to be allocated.
> [Fiona] IVs greater than 16 bytes can be used, right? If so change to "a
> minimum of 16 bytes must be allocated". Same below.
>
> > + * 2) Zero, in which case data points to J0. In this case
> > + * 16 bytes of J0 should be passed where J0 is defined
> > + * by NIST SP800-38D.
> > + *
> > */
> > } iv; /**< Initialisation vector parameters */
> >
> > @@ -383,11 +384,6 @@ struct rte_crypto_aead_xform {
> > * specified as number of bytes from start of crypto
> > * operation (rte_crypto_op).
> > *
> > - * - For GCM mode, this is either the IV (if the length
> > - * is 96 bits) or J0 (for other sizes), where J0 is as
> > - * defined by NIST SP800-38D. Regardless of the IV
> > - * length, a full 16 bytes needs to be allocated.
> > - *
> > * - For CCM mode, the first byte is reserved, and the
> > * nonce should be written starting at &iv[1] (to allow
> > * space for the implementation to write in the flags @@ -
> 401,8
> > +397,13 @@ struct rte_crypto_aead_xform {
> > uint16_t length;
> > /**< Length of valid IV data.
> > *
> > - * - For GCM mode, this is either 12 (for 96-bit IVs)
> > - * or 16, in which case data points to J0.
> > + * - For GCM mode, this is either:
> > + * 1) Number greater or equal to one, which means that IV
> > + * is used and J0 will be computed internally, 16 bytes
> > + * needs to be allocated.
> > + * 2) Zero, in which case data points to J0. In this case
> > + * 16 bytes of J0 should be passed where J0 is defined
> > + * by NIST SP800-38D.
> > *
> > * - For CCM mode, this is the length of the nonce,
> > * which can be in the range 7 to 13 inclusive.
> > --
> > 2.1.0
@@ -152,11 +152,6 @@ struct rte_crypto_cipher_xform {
*
* - For block ciphers in CTR mode, this is the counter.
*
- * - For GCM mode, this is either the IV (if the length
- * is 96 bits) or J0 (for other sizes), where J0 is as
- * defined by NIST SP800-38D. Regardless of the IV
- * length, a full 16 bytes needs to be allocated.
- *
* - For CCM mode, the first byte is reserved, and the
* nonce should be written starting at &iv[1] (to allow
* space for the implementation to write in the flags
@@ -184,9 +179,6 @@ struct rte_crypto_cipher_xform {
* of the counter (which must be the same as the block
* length of the cipher).
*
- * - For GCM mode, this is either 12 (for 96-bit IVs)
- * or 16, in which case data points to J0.
- *
* - For CCM mode, this is the length of the nonce,
* which can be in the range 7 to 13 inclusive.
*/
@@ -306,9 +298,10 @@ struct rte_crypto_auth_xform {
* specified as number of bytes from start of crypto
* operation (rte_crypto_op).
*
- * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
- * for AES-GMAC, this is the authentication
- * Initialisation Vector (IV) value.
+ * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
+ * this is the authentication Initialisation Vector
+ * (IV) value. For AES-GMAC IV description please refer
+ * to the field `length` in iv struct.
*
* - For KASUMI in F9 mode and other authentication
* algorithms, this field is not used.
@@ -325,6 +318,14 @@ struct rte_crypto_auth_xform {
* - For KASUMI in F9 mode and other authentication
* algorithms, this field is not used.
*
+ * - For GMAC mode, this is either:
+ * 1) Number greater or equal to one, which means that IV
+ * is used and J0 will be computed internally, 16 bytes
+ * needs to be allocated.
+ * 2) Zero, in which case data points to J0. In this case
+ * 16 bytes of J0 should be passed where J0 is defined
+ * by NIST SP800-38D.
+ *
*/
} iv; /**< Initialisation vector parameters */
@@ -383,11 +384,6 @@ struct rte_crypto_aead_xform {
* specified as number of bytes from start of crypto
* operation (rte_crypto_op).
*
- * - For GCM mode, this is either the IV (if the length
- * is 96 bits) or J0 (for other sizes), where J0 is as
- * defined by NIST SP800-38D. Regardless of the IV
- * length, a full 16 bytes needs to be allocated.
- *
* - For CCM mode, the first byte is reserved, and the
* nonce should be written starting at &iv[1] (to allow
* space for the implementation to write in the flags
@@ -401,8 +397,13 @@ struct rte_crypto_aead_xform {
uint16_t length;
/**< Length of valid IV data.
*
- * - For GCM mode, this is either 12 (for 96-bit IVs)
- * or 16, in which case data points to J0.
+ * - For GCM mode, this is either:
+ * 1) Number greater or equal to one, which means that IV
+ * is used and J0 will be computed internally, 16 bytes
+ * needs to be allocated.
+ * 2) Zero, in which case data points to J0. In this case
+ * 16 bytes of J0 should be passed where J0 is defined
+ * by NIST SP800-38D.
*
* - For CCM mode, this is the length of the nonce,
* which can be in the range 7 to 13 inclusive.