From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by dpdk.space (Postfix) with ESMTP id EC127A00E6
for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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 <arkadiuszx.kusztal@intel.com>
To: dev@dpdk.org
Cc: akhil.goyal@nxp.com, fiona.trahe@intel.com, pablo.de.lara.guarch@intel.com,
Arek Kusztal <arkadiuszx.kusztal@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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 <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.
+ * 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