Hi Arek,

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, April 17, 2019 8:37 AM
> To: dev@dpdk.org
> Cc: akhil.go...@nxp.com; Trahe, Fiona <fiona.tr...@intel.com>; De Lara 
> Guarch, Pablo
> <pablo.de.lara.gua...@intel.com>; Kusztal, ArkadiuszX 
> <arkadiuszx.kusz...@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.kusz...@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

Reply via email to