From: Anoob Joseph <anoobj@marvell.com>
To: Akhil Goyal <akhil.goyal@nxp.com>, Radu Nicolau <radu.nicolau@intel.com>
Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>,
Tejasree Kondoj <ktejasree@marvell.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v3] examples/ipsec-secgw: support 192/256 AES key sizes
Date: Sun, 5 Apr 2020 17:10:59 +0000 [thread overview]
Message-ID: <MN2PR18MB2877F066CA18175AA4EBEB33DFC50@MN2PR18MB2877.namprd18.prod.outlook.com> (raw)
In-Reply-To: <VE1PR04MB66394D7FD0F7AF01D4946BB8E6C50@VE1PR04MB6639.eurprd04.prod.outlook.com>
Hi Akhil,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Sunday, April 5, 2020 8:54 PM
> To: Anoob Joseph <anoobj@marvell.com>; Radu Nicolau
> <radu.nicolau@intel.com>
> Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>; Tejasree Kondoj
> <ktejasree@marvell.com>; dev@dpdk.org
> Subject: [EXT] RE: [PATCH v3] examples/ipsec-secgw: support 192/256 AES key
> sizes
>
> External Email
>
> ----------------------------------------------------------------------
> Hi Anoob,
>
> >
> > Adding support for the following,
> > 1. AES-192-GCM
> > 2. AES-256-GCM
> > 3. AES-192-CBC
> >
> > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
> > ---
> > v3:
> > * Fixed incorrect AES-GCM key length being printed during app startup
> > * Introduced new macro 'SALT_SIZE' to make the usage more obvious (AES-
> GCM
> > key has key following 4 byte salt)
> > * Minor cleanup for the existing code.
>
> I believe GCM keys are extended by 4 bytes to include the SALT value in many
> apps.
> We may add a comment that it is including the SALT value, but it makes more
> confusing now.
>
> The length which is being printed is 16Bytes but we expect the user to have
> 20Bytes In the ep0.cfg file. This will be confusing also to configure the packet
> capturing APPs Like wireshark which accepts 20Byte keys in case of GCM.
[Anoob] The ones I've edited is just internal data structures. These are not exposed and not directly printed anywhere.
spi_in( 51):aes-128-gcm mode:IP4Tunnel 10.0.10.1 10.0.10.2 type:inline-protocol-offload
spi_in( 52):aes-192-gcm mode:IP4Tunnel 10.0.20.1 10.0.20.2 type:inline-protocol-offload
spi_in( 53):aes-256-gcm mode:IP4Tunnel 10.0.30.1 10.0.30.2 type:inline-protocol-offload
Also, my initial patch didn't try to address this aspect. In that patch, I had the following addition, in which key length was clearly not matching the string.
{
.keyword = "aes-192-gcm",
.algo = RTE_CRYPTO_AEAD_AES_GCM,
.iv_len = 8,
.block_size = 4,
.key_len = 28,
.digest_len = 16,
.aad_len = 8,
},
In either case, the "misleading" part in config file would stay as the string would be "aes-128-gcm"/"aes-192-gcm"/"aes-256-gcm", and the key specified will have additional 4 bytes. Please do comment inline on what you think is the right approach. You can check if you are fine with v2 approach. I can resend that with a minor change required in the print.
One more thing. I was just checking the ipsec-secgw documentation of AEAD keys. I think we need to update that as well.
Syntax: Hexadecimal bytes (0x0-0xFF) concatenate by colon symbol ':'. The number of bytes should be as same as the specified AEAD algorithm key size.
For example: aead_key A1:B2:C3:D4:A1:B2:C3:D4:A1:B2:C3:D4: A1:B2:C3:D4
Can you advice on what should be the approach here?
>
> >
> > v2:
> > * Updated doc and release notes
> >
> > doc/guides/rel_notes/release_20_05.rst | 7 ++++++
> > doc/guides/sample_app_ug/ipsec_secgw.rst | 3 +++
> > examples/ipsec-secgw/ipsec.h | 3 ++-
> > examples/ipsec-secgw/sa.c | 38 ++++++++++++++++++++++++++------
> > 4 files changed, 43 insertions(+), 8 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/release_20_05.rst
> > b/doc/guides/rel_notes/release_20_05.rst
> > index 1dfcfcc..c0b0625 100644
> > --- a/doc/guides/rel_notes/release_20_05.rst
> > +++ b/doc/guides/rel_notes/release_20_05.rst
> > @@ -70,6 +70,13 @@ New Features
> > by making use of the event device capabilities. The event mode
> > currently supports
> > only inline IPsec protocol offload.
> >
> > +* **Added 192/256 AES key sizes in ipsec-secgw application.**
> > +
> > + Updated ipsec-secgw application to support the following key sizes,
> > + - AES-192-CBC
> > + - AES-192-GCM
> > + - AES-256-GCM
> > +
> >
> > Removed Items
> > -------------
> > diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst
> > b/doc/guides/sample_app_ug/ipsec_secgw.rst
> > index 038f593..f5e94bf 100644
> > --- a/doc/guides/sample_app_ug/ipsec_secgw.rst
> > +++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
> > @@ -538,6 +538,7 @@ where each options means:
> >
> > * *null*: NULL algorithm
> > * *aes-128-cbc*: AES-CBC 128-bit algorithm
> > + * *aes-192-cbc*: AES-CBC 192-bit algorithm
> > * *aes-256-cbc*: AES-CBC 256-bit algorithm
> > * *aes-128-ctr*: AES-CTR 128-bit algorithm
> > * *3des-cbc*: 3DES-CBC 192-bit algorithm @@ -593,6 +594,8 @@ where
> > each options means:
> > * Available options:
> >
> > * *aes-128-gcm*: AES-GCM 128-bit algorithm
> > + * *aes-192-gcm*: AES-GCM 192-bit algorithm
> > + * *aes-256-gcm*: AES-GCM 256-bit algorithm
> >
> > * Syntax: *cipher_algo <your algorithm>*
> >
> > diff --git a/examples/ipsec-secgw/ipsec.h
> > b/examples/ipsec-secgw/ipsec.h index f8f29f9..476a6d5 100644
> > --- a/examples/ipsec-secgw/ipsec.h
> > +++ b/examples/ipsec-secgw/ipsec.h
> > @@ -73,6 +73,7 @@ struct ip_addr {
> > };
> >
> > #define MAX_KEY_SIZE 32
> > +#define SALT_SIZE 4
> >
> > /*
> > * application wide SA parameters
> > @@ -133,7 +134,7 @@ struct ipsec_sa {
> > #define IP6_TRANSPORT (1 << 4)
> > struct ip_addr src;
> > struct ip_addr dst;
> > - uint8_t cipher_key[MAX_KEY_SIZE];
> > + uint8_t cipher_key[MAX_KEY_SIZE + SALT_SIZE];
> > uint16_t cipher_key_len;
> > uint8_t auth_key[MAX_KEY_SIZE];
> > uint16_t auth_key_len;
> > diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
> > index 0eb52d1..fc6bc97 100644
> > --- a/examples/ipsec-secgw/sa.c
> > +++ b/examples/ipsec-secgw/sa.c
> > @@ -77,6 +77,13 @@ const struct supported_cipher_algo cipher_algos[] = {
> > .key_len = 16
> > },
> > {
> > + .keyword = "aes-192-cbc",
> > + .algo = RTE_CRYPTO_CIPHER_AES_CBC,
> > + .iv_len = 16,
> > + .block_size = 16,
> > + .key_len = 24
> > + },
> > + {
> > .keyword = "aes-256-cbc",
> > .algo = RTE_CRYPTO_CIPHER_AES_CBC,
> > .iv_len = 16,
> > @@ -127,7 +134,25 @@ const struct supported_aead_algo aead_algos[] = {
> > .algo = RTE_CRYPTO_AEAD_AES_GCM,
> > .iv_len = 8,
> > .block_size = 4,
> > - .key_len = 20,
> > + .key_len = 16,
> > + .digest_len = 16,
> > + .aad_len = 8,
> > + },
> > + {
> > + .keyword = "aes-192-gcm",
> > + .algo = RTE_CRYPTO_AEAD_AES_GCM,
> > + .iv_len = 8,
> > + .block_size = 4,
> > + .key_len = 24,
> > + .digest_len = 16,
> > + .aad_len = 8,
> > + },
> > + {
> > + .keyword = "aes-256-gcm",
> > + .algo = RTE_CRYPTO_AEAD_AES_GCM,
> > + .iv_len = 8,
> > + .block_size = 4,
> > + .key_len = 32,
> > .digest_len = 16,
> > .aad_len = 8,
> > }
> > @@ -495,16 +520,14 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
> > return;
> >
> > key_len = parse_key_string(tokens[ti],
> > - rule->cipher_key);
> > + rule->cipher_key) - SALT_SIZE;
> > APP_CHECK(key_len == rule->cipher_key_len, status,
> > "unrecognized input \"%s\"", tokens[ti]);
> > if (status->status < 0)
> > return;
> >
> > - key_len -= 4;
> > - rule->cipher_key_len = key_len;
> > - memcpy(&rule->salt,
> > - &rule->cipher_key[key_len], 4);
> > + memcpy(&rule->salt, &rule->cipher_key[key_len],
> > + SALT_SIZE);
> >
> > aead_algo_p = 1;
> > continue;
> > @@ -751,7 +774,8 @@ print_one_sa_rule(const struct ipsec_sa *sa, int
> inbound)
> > }
> >
> > for (i = 0; i < RTE_DIM(aead_algos); i++) {
> > - if (aead_algos[i].algo == sa->aead_algo) {
> > + if (aead_algos[i].algo == sa->aead_algo &&
> > + aead_algos[i].key_len == sa->cipher_key_len) {
> > printf("%s ", aead_algos[i].keyword);
> > break;
> > }
> > --
> > 2.7.4
next prev parent reply other threads:[~2020-04-05 17:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 3:17 [dpdk-dev] [PATCH] " Anoob Joseph
2020-03-25 18:37 ` Akhil Goyal
2020-03-26 2:21 ` Anoob Joseph
2020-03-26 9:03 ` Akhil Goyal
2020-03-26 11:22 ` [dpdk-dev] [PATCH v2] " Anoob Joseph
2020-04-03 2:53 ` [dpdk-dev] [PATCH v3] " Anoob Joseph
2020-04-05 15:24 ` Akhil Goyal
2020-04-05 17:10 ` Anoob Joseph [this message]
2020-04-06 6:42 ` Akhil Goyal
2020-04-06 6:46 ` Anoob Joseph
2020-04-07 6:30 ` [dpdk-dev] [PATCH v4] " Anoob Joseph
2020-04-15 18:15 ` Akhil Goyal
2020-04-17 21:03 ` 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=MN2PR18MB2877F066CA18175AA4EBEB33DFC50@MN2PR18MB2877.namprd18.prod.outlook.com \
--to=anoobj@marvell.com \
--cc=akhil.goyal@nxp.com \
--cc=dev@dpdk.org \
--cc=ktejasree@marvell.com \
--cc=pathreya@marvell.com \
--cc=radu.nicolau@intel.com \
/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).