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 35419A0577; Mon, 6 Apr 2020 08:42:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 81B141BED8; Mon, 6 Apr 2020 08:42:03 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140052.outbound.protection.outlook.com [40.107.14.52]) by dpdk.org (Postfix) with ESMTP id 1229C2BE9 for ; Mon, 6 Apr 2020 08:42:02 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ociNaTU7zjPGzfw5906MOZah8IYRfQFMZJngRDneeYzpD/Kj/VNh3YXKSrsozggG/PucZtAUSNQdv7US+uel180DeDlY6raMnJBb3Rl5POx7AIEFwDBv1S2/xnUzp5e57o/BJK1Sl8WTDUDN5z+dE2cnUhWbo2YKk61e1FnCtWdjpvPfE4ZEIDwy8x2re0ArUJh2uM2aOOOVAzwygsmbCHdsRVjanrd793aHLR7OE8cF8SU/DWWQEOomGc1ylHwOBDPQVEjPsnLQYzNL0O4m8pclV2ei+tlGzFppZEvOvzET95iyxPO5laDFkQ0cGK2HoKRkEWyvhNE/D6jgwWfZCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=odtbTYhL/lZ1jMuOl1C2Yy+5UWKeG2A2VE6FWzJh+zk=; b=N0U+9xxGdPePRSnw1mc0uuqRDL0PT/jAa6lHBT5GR6zQ/nFB7JBEu6MfexlA+IwvVSzOb8UZhkdZ4empdLGnkvKN92aouonlB+WR1/QJJdFYQsCRvtL5unQJcfNcMLCnj0yx3DnKBkJMEupQXYM8pVE3mEehNGfv9czIRgW51QBPdE+kvop0Ilc4CeG0fT8nAVr1aWDZPWpel4Ia/8g1v8bZr2Av9Zg/2JDbNwWsKq3SBfgxY8JgTk+X/omRE5tLEx1loiyCYcqKbEn02Z4bjvrF/pN03Oof6WP9a1IJ3IFUiPywajyFS37XeHlBp7H1+Gqt7kjjeoIc2kiGbuGKMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=odtbTYhL/lZ1jMuOl1C2Yy+5UWKeG2A2VE6FWzJh+zk=; b=DrfuvjnWbw2A50OmloKXdL8GbvSG7O++kr+d+SUp2gZEqkEPmg6r3J6gtkwiuHXIXfE95JLXLHlo2A9Du+jTF8Zuf25ulONLRAs/QcuvynXr5OhQPFvPy+loh78IdMJ4P5yU3LXkmMG2fPUfshHZLJxLe5KNOLGwNlYTeDOgO9Q= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (2603:10a6:803:129::11) by VE1PR04MB6494.eurprd04.prod.outlook.com (2603:10a6:803:127::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Mon, 6 Apr 2020 06:42:01 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::8060:a35c:4858:c490]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::8060:a35c:4858:c490%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 06:42:01 +0000 From: Akhil Goyal To: Anoob Joseph , Radu Nicolau CC: Narayana Prasad Raju Athreya , Tejasree Kondoj , "dev@dpdk.org" Thread-Topic: [PATCH v3] examples/ipsec-secgw: support 192/256 AES key sizes Thread-Index: AQHWCWMMDxR+qWxeNUurZFUGmGVANKhqp9fggAAfvYCAAOBTUA== Date: Mon, 6 Apr 2020 06:42:01 +0000 Message-ID: References: <1585221759-23016-1-git-send-email-anoobj@marvell.com> <1585882384-28213-1-git-send-email-anoobj@marvell.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [45.118.166.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: dfe033f8-9f34-460d-c77e-08d7d9f59c8b x-ms-traffictypediagnostic: VE1PR04MB6494: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VE1PR04MB6639.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(376002)(366004)(346002)(66946007)(478600001)(52536014)(6506007)(81166006)(54906003)(2906002)(7696005)(316002)(66476007)(66556008)(64756008)(66446008)(76116006)(86362001)(110136005)(4326008)(5660300002)(186003)(9686003)(44832011)(81156014)(8676002)(8936002)(71200400001)(33656002)(55016002)(26005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: l+oKkBnDqp2p0tCB1Ies6Q0+nNaqzsUmNBL0uUhGjsvIn0+38pF0Gz6UGoPbzA+M+fYheFukwQjr7nx9swBcGIjwUZLFq4rnMGuDuWFVLg8rXczTciIYg/njZbr3ydMtZlBdR5YNKyBjua9d3jcsSG5z489MYUyRqKQ46WuvNR6EHizw+ERa7cjjONotF1K5eiatvtWe6f/oYGH3dqD9a1ZSGJnpW1ysLgUIia3ZxKH73GjejOLSSWRrJGAoH3tTxygxw2YFfr3PpDWa1tRV/aYkreQmx+k0RkNDENXzquc+aWivCAmIYMf3e1LpDLOQwH7oX+4dLs2UxZakst07mf/9ZJzlnAZoKFjgm/l5xsMfaY7MkWFKuuCVnzNmbNqa0Tl9WEjMp0z0TCkdcXDi7FK55WCOJu9/5dDfMMZoMkRBDbJBkwm8rBIUYPB94NBD x-ms-exchange-antispam-messagedata: xjCFxu/77ikg6sXcFx07a1zi3JzlYhTw90k97XDpc+1RfbDDrcDC0su92wQbSYNpVRudzsyhLDjfsqQPH2g+GcBHyLDkWmMZjVCokOv7SNqWmWA3FiIf98okY8vNp7x3wirHErkAltbtG6npqV/ZqQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: dfe033f8-9f34-460d-c77e-08d7d9f59c8b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 06:42:01.2465 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LBaEZOTuw6QiK1W05OFFacBz05Mofwh8TVSMfs55OlHuxgF3LgYTeX1nApIWbXhHaPCrPs32PEimQ1LT5sWtvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6494 Subject: Re: [dpdk-dev] [PATCH v3] examples/ipsec-secgw: support 192/256 AES key sizes 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" > > Hi Anoob, > > > > > > > > Adding support for the following, > > > 1. AES-192-GCM > > > 2. AES-256-GCM > > > 3. AES-192-CBC > > > > > > Signed-off-by: Anoob Joseph > > > Signed-off-by: Tejasree Kondoj > > > --- > > > v3: > > > * Fixed incorrect AES-GCM key length being printed during app startup > > > * Introduced new macro 'SALT_SIZE' to make the usage more obvious (AE= S- > > 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 t= he packet > > capturing APPs Like wireshark which accepts 20Byte keys in case of GCM. >=20 > [Anoob] The ones I've edited is just internal data structures. These are = not > exposed and not directly printed anywhere. >=20 > 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 >=20 > 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 stri= ng. >=20 > { > .keyword =3D "aes-192-gcm", > .algo =3D RTE_CRYPTO_AEAD_AES_GCM, > .iv_len =3D 8, > .block_size =3D 4, > .key_len =3D 28, > .digest_len =3D 16, > .aad_len =3D 8, > }, >=20 > In either case, the "misleading" part in config file would stay as the st= ring 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 th= e right > approach. You can check if you are fine with v2 approach. I can resend th= at with > a minor change required in the print. >=20 > One more thing. I was just checking the ipsec-secgw documentation of AEAD > keys. I think we need to update that as well. >=20 > Syntax: Hexadecimal bytes (0x0-0xFF) concatenate by colon symbol ':'. The > number of bytes should be as same as the specified AEAD algorithm key siz= e. >=20 > For example: aead_key A1:B2:C3:D4:A1:B2:C3:D4:A1:B2:C3:D4: A1:B2:C3:D4 >=20 > Can you advice on what should be the approach here? >=20 I think it is better to have the key len include the 4 bytes of SALT and cf= g file has those 4 bytes Inline with the key. We can add a print to specify that last 4 bytes are sa= lt. And Yes for AEAD doc, we can add a statement that keylen should include the= the 4bytes of SALT. And user should specify the extra 4 bytes. So I believe your v2 was good enough with some additional documentations.