From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id D37C11B5EE for ; Wed, 17 Apr 2019 13:38:06 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2019 04:38:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,361,1549958400"; d="scan'208";a="143471724" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga003.jf.intel.com with ESMTP; 17 Apr 2019 04:38:05 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.115]) by IRSMSX153.ger.corp.intel.com ([169.254.9.61]) with mapi id 14.03.0415.000; Wed, 17 Apr 2019 12:38:04 +0100 From: "Trahe, Fiona" To: "Kusztal, ArkadiuszX" , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , "De Lara Guarch, Pablo" , "Trahe, Fiona" Thread-Topic: [PATCH] cryptodev: add an option to support both iv and J0 for GCM Thread-Index: AQHU9PDgi0SxvSZ7gEans4gnY8IRO6ZAOR8g Date: Wed, 17 Apr 2019 11:38:03 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43589743C51@IRSMSX101.ger.corp.intel.com> References: <20190417073641.2436-1-arkadiuszx.kusztal@intel.com> In-Reply-To: <20190417073641.2436-1-arkadiuszx.kusztal@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjA5MjI5M2UtZTMzYS00NDJhLWJkZDItNjdkZmRjNDc5YmMzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiemhIbFhqSWVXdGN2ZFF6cTZ1SmYwMndiXC9hb2w5NDlFWkg1Vk9CR29oTFdVVnd4bkpyZGM4XC9sMWFkR0gxcDRwIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 11:38:07 -0000 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 ; De Lara Gu= arch, Pablo > ; Kusztal, ArkadiuszX > Subject: [PATCH] cryptodev: add an option to support both iv and J0 for G= CM >=20 > This patch adds an option to support both IV (of all supported sizes) > and J0 when using Galois Counter Mode of crypto operation. >=20 > Signed-off-by: Arek Kusztal > --- > lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------= ------ > 1 file changed, 19 insertions(+), 18 deletions(-) >=20 > 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=20 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 */ >=20 > @@ -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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 20433A00E6 for ; Wed, 17 Apr 2019 13:38:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 89D8E1B5F3; Wed, 17 Apr 2019 13:38:09 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id D37C11B5EE for ; Wed, 17 Apr 2019 13:38:06 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2019 04:38:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,361,1549958400"; d="scan'208";a="143471724" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga003.jf.intel.com with ESMTP; 17 Apr 2019 04:38:05 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.115]) by IRSMSX153.ger.corp.intel.com ([169.254.9.61]) with mapi id 14.03.0415.000; Wed, 17 Apr 2019 12:38:04 +0100 From: "Trahe, Fiona" To: "Kusztal, ArkadiuszX" , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , "De Lara Guarch, Pablo" , "Trahe, Fiona" Thread-Topic: [PATCH] cryptodev: add an option to support both iv and J0 for GCM Thread-Index: AQHU9PDgi0SxvSZ7gEans4gnY8IRO6ZAOR8g Date: Wed, 17 Apr 2019 11:38:03 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43589743C51@IRSMSX101.ger.corp.intel.com> References: <20190417073641.2436-1-arkadiuszx.kusztal@intel.com> In-Reply-To: <20190417073641.2436-1-arkadiuszx.kusztal@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjA5MjI5M2UtZTMzYS00NDJhLWJkZDItNjdkZmRjNDc5YmMzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiemhIbFhqSWVXdGN2ZFF6cTZ1SmYwMndiXC9hb2w5NDlFWkg1Vk9CR29oTFdVVnd4bkpyZGM4XC9sMWFkR0gxcDRwIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190417113803.0QhOvNsbpJLOycj1DeJhrVlTXs7OAOm1KwdwxFvSvLU@z> 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 ; De Lara Gu= arch, Pablo > ; Kusztal, ArkadiuszX > Subject: [PATCH] cryptodev: add an option to support both iv and J0 for G= CM >=20 > This patch adds an option to support both IV (of all supported sizes) > and J0 when using Galois Counter Mode of crypto operation. >=20 > Signed-off-by: Arek Kusztal > --- > lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------= ------ > 1 file changed, 19 insertions(+), 18 deletions(-) >=20 > 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=20 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 */ >=20 > @@ -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