DPDK patches and discussions
 help / color / mirror / Atom feed
From: Marcin Smoczynski <marcinx.smoczynski@intel.com>
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 <marcinx.smoczynski@intel.com>
Subject: [dpdk-dev] [PATCH] examples/ipsec-secgw: fix gcm iv length
Date: Thu, 31 Oct 2019 15:04:45 +0100	[thread overview]
Message-ID: <20191031140445.4564-1-marcinx.smoczynski@intel.com> (raw)

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 <marcinx.smoczynski@intel.com>
---
 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


             reply	other threads:[~2019-10-31 14:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31 14:04 Marcin Smoczynski [this message]
2019-11-05 23:00 ` Akhil Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191031140445.4564-1-marcinx.smoczynski@intel.com \
    --to=marcinx.smoczynski@intel.com \
    --cc=akhil.goyal@nxp.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).