From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 11D74A00C4; Thu, 31 Oct 2019 15:07:30 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 868F71C295; Thu, 31 Oct 2019 15:07:29 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 593941C25A; Thu, 31 Oct 2019 15:07:28 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2019 07:07:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,250,1569308400"; d="scan'208";a="211575800" Received: from msmoczyx-mobl.ger.corp.intel.com ([10.103.104.106]) by fmsmga001.fm.intel.com with ESMTP; 31 Oct 2019 07:07:21 -0700 From: Marcin Smoczynski To: akhil.goyal@nxp.com, konstantin.ananyev@intel.com, pablo.de.lara.guarch@intel.com Cc: dev@dpdk.org, stable@dpdk.org, fiona.trahe@intel.com, Marcin Smoczynski Date: Thu, 31 Oct 2019 15:04:45 +0100 Message-Id: <20191031140445.4564-1-marcinx.smoczynski@intel.com> X-Mailer: git-send-email 2.21.0.windows.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH] examples/ipsec-secgw: fix gcm iv length 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" The example IPsec application does not work properly when using AES-GCM with crypto_openssl. ESP with AES-GCM uses standard 96bit long algorithm IV ([1]) which later concatenated with be32(1) forms a J0 block. GCM specification ([2], chapter 7.1) states that when length of IV is different than 96b, in order to format a J0 block, GHASH function must be used. According to specification ([2], chapter 5.1.1) GCM implementations should support standard 96bit IVs, other lengths are optional. Every DPDK cryptodev supports 96bit IV and few of them supports 128bit IV as well (openssl, mrvl, ccp). When passing iv::length=16 to a cryptodev which does support standard IVs only (e.g. qat) it implicitly uses starting 96 bits. On the other hand, openssl follows specification and uses GHASH to compute J0 for that case which results in different than expected J0 values used for encryption/decryption. Fix an inability to use AES-GCM with crypto_openssl by changing IV length to the standard value of 12. [1] RFC4106, section "4. Nonce format" and "3.1. Initialization Vector" https://tools.ietf.org/html/rfc4106 [2] NIST SP800-38D https://csrc.nist.gov/publications/detail/sp/800-38d/final Fixes: 0fbd75a99f ("cryptodev: move IV parameters to session") Cc: stable@dpdk.org Signed-off-by: Marcin Smoczynski --- examples/ipsec-secgw/sa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c index 14ee94731..041e402a9 100644 --- a/examples/ipsec-secgw/sa.c +++ b/examples/ipsec-secgw/sa.c @@ -926,7 +926,7 @@ sa_add_rules(struct sa_ctx *sa_ctx, const struct ipsec_sa entries[], } if (sa->aead_algo == RTE_CRYPTO_AEAD_AES_GCM) { - iv_length = 16; + iv_length = 12; sa_ctx->xf[idx].a.type = RTE_CRYPTO_SYM_XFORM_AEAD; sa_ctx->xf[idx].a.aead.algo = sa->aead_algo; -- 2.17.1