patches for DPDK stable branches
 help / color / Atom feed
* [dpdk-stable] [PATCH] examples/ipsec-secgw: fix gcm iv length
@ 2019-10-31 14:04 Marcin Smoczynski
  2019-11-05 23:00 ` Akhil Goyal
  0 siblings, 1 reply; 2+ messages in thread
From: Marcin Smoczynski @ 2019-10-31 14:04 UTC (permalink / raw)
  To: akhil.goyal, konstantin.ananyev, pablo.de.lara.guarch
  Cc: dev, stable, fiona.trahe, Marcin Smoczynski

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [dpdk-stable] [PATCH] examples/ipsec-secgw: fix gcm iv length
  2019-10-31 14:04 [dpdk-stable] [PATCH] examples/ipsec-secgw: fix gcm iv length Marcin Smoczynski
@ 2019-11-05 23:00 ` Akhil Goyal
  0 siblings, 0 replies; 2+ messages in thread
From: Akhil Goyal @ 2019-11-05 23:00 UTC (permalink / raw)
  To: Marcin Smoczynski, konstantin.ananyev, pablo.de.lara.guarch
  Cc: dev, stable, fiona.trahe



> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf
> .org%2Fhtml%2Frfc4106&amp;data=02%7C01%7Cakhil.goyal%40nxp.com%7Cd
> 24096cff31845d1619e08d75e0babaa%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637081276526121698&amp;sdata=DInvN3miogcG9WqkuRlUQ%
> 2BzuqMRs2P63CJA%2BojPx6vU%3D&amp;reserved=0
> [2] NIST SP800-38D
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.
> gov%2Fpublications%2Fdetail%2Fsp%2F800-
> 38d%2Ffinal&amp;data=02%7C01%7Cakhil.goyal%40nxp.com%7Cd24096cff318
> 45d1619e08d75e0babaa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> 7C637081276526121698&amp;sdata=EU6tJ9qvzpzh1b8j%2BsPjc18E3CUrXkSZ7c
> O6xvOmv1U%3D&amp;reserved=0
> 
> Fixes: 0fbd75a99f ("cryptodev: move IV parameters to session")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Marcin Smoczynski <marcinx.smoczynski@intel.com>
> ---
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
Applied to dpdk-next-crypto

Thanks.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-31 14:04 [dpdk-stable] [PATCH] examples/ipsec-secgw: fix gcm iv length Marcin Smoczynski
2019-11-05 23:00 ` Akhil Goyal

patches for DPDK stable branches

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/stable/0 stable/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 stable stable/ http://inbox.dpdk.org/stable \
		stable@dpdk.org
	public-inbox-index stable


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.stable


AGPL code for this site: git clone https://public-inbox.org/ public-inbox