From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id EDBE41B4E3 for ; Wed, 17 Apr 2019 09:40:20 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2019 00:40:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,361,1549958400"; d="scan'208";a="162323036" Received: from akusztax-mobl.ger.corp.intel.com ([10.104.116.188]) by fmsmga002.fm.intel.com with ESMTP; 17 Apr 2019 00:40:17 -0700 From: Arek Kusztal To: dev@dpdk.org Cc: akhil.goyal@nxp.com, fiona.trahe@intel.com, pablo.de.lara.guarch@intel.com, Arek Kusztal Date: Wed, 17 Apr 2019 09:36:41 +0200 Message-Id: <20190417073641.2436-1-arkadiuszx.kusztal@intel.com> X-Mailer: git-send-email 2.19.1.windows.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [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 07:40:21 -0000 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 --- 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. + * 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 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 EC127A00E6 for ; Wed, 17 Apr 2019 09:40:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 905561B540; Wed, 17 Apr 2019 09:40:22 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id EDBE41B4E3 for ; Wed, 17 Apr 2019 09:40:20 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2019 00:40:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,361,1549958400"; d="scan'208";a="162323036" Received: from akusztax-mobl.ger.corp.intel.com ([10.104.116.188]) by fmsmga002.fm.intel.com with ESMTP; 17 Apr 2019 00:40:17 -0700 From: Arek Kusztal To: dev@dpdk.org Cc: akhil.goyal@nxp.com, fiona.trahe@intel.com, pablo.de.lara.guarch@intel.com, Arek Kusztal Date: Wed, 17 Apr 2019 09:36:41 +0200 Message-Id: <20190417073641.2436-1-arkadiuszx.kusztal@intel.com> X-Mailer: git-send-email 2.19.1.windows.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [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" Content-Type: text/plain; charset="UTF-8" Message-ID: <20190417073641.qa-SnCDtjQyPdNiQqf4LXiCEcYVPWyqI80CzcW4dumY@z> 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 --- 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. + * 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