From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <arkadiuszx.kusztal@intel.com> Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 57D8D1B2AC for <dev@dpdk.org>; Wed, 20 Mar 2019 19:47:31 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2019 11:47:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,249,1549958400"; d="scan'208,217";a="330408322" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga005.fm.intel.com with ESMTP; 20 Mar 2019 11:47:29 -0700 Received: from hasmsx107.ger.corp.intel.com (10.184.198.27) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 20 Mar 2019 11:47:29 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.144]) by hasmsx107.ger.corp.intel.com ([169.254.2.23]) with mapi id 14.03.0415.000; Wed, 20 Mar 2019 20:47:26 +0200 From: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com> To: "dev@dpdk.org" <dev@dpdk.org>, "Trahe, Fiona" <fiona.trahe@intel.com>, "Doherty, Declan" <declan.doherty@intel.com>, "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>, "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>, "ravi1.kumar@amd.com" <ravi1.kumar@amd.com>, "tdu@semihalf.com" <tdu@semihalf.com>, "lironh@marvell.com" <lironh@marvell.com>, "walan@marvell.com" <walan@marvell.com> Thread-Topic: [RFC] cryptodev/sym: GCM IV len != 12 byte case Thread-Index: AdTfSeDR58Xinq03QgGH1UrdmGxm2Q== Date: Wed, 20 Mar 2019 18:47:26 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B14CD9F@hasmsx109.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.104.12.183] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 20 Mar 2019 18:47:32 -0000 Hi all, There is a proposition to amend a bit API due to the following lines: * - For GCM mode, this is either 12 (for 96-bit IVs) * or 16, in which case data points to J0. ... } iv; /**< Initialisation vector parameters */ Problem arise when driver cannot support J0 input, right now we know that O= PENSSL PMD works with IV instead of J0 when iv_len !=3D 12. So it may be that we have to somehow support both. There are two options, a= nd I am very curious about community opinion. 1) Add a flag to aead_xform.iv to supports IV or J0 like this: uint8_t IV_used; And this could be reflected in capabilities. Of course for 96bits IV this f= ield would not be used, so it would had to be set only for iv.length !=3D 1= 2 2) Change API comments to something like: * - For GCM mode, this is either 12 (for 96-bit IVs), * - for IV length different than 96 bits it is or J0 or IV, * - refer to specific driver rst or capabilities which one * - is supported, etc. (J0 by definition is of 16 bytes len) I cc'ing maintainers of drivers that support iv_len !=3D 16 bytes. Cannot check how it works as I have no hw. Regards, Arek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id E890AA00E6 for <public@inbox.dpdk.org>; Wed, 20 Mar 2019 19:47:53 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 296D61B3A5; Wed, 20 Mar 2019 19:47:36 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 57D8D1B2AC for <dev@dpdk.org>; Wed, 20 Mar 2019 19:47:31 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2019 11:47:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,249,1549958400"; d="scan'208,217";a="330408322" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga005.fm.intel.com with ESMTP; 20 Mar 2019 11:47:29 -0700 Received: from hasmsx107.ger.corp.intel.com (10.184.198.27) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 20 Mar 2019 11:47:29 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.144]) by hasmsx107.ger.corp.intel.com ([169.254.2.23]) with mapi id 14.03.0415.000; Wed, 20 Mar 2019 20:47:26 +0200 From: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com> To: "dev@dpdk.org" <dev@dpdk.org>, "Trahe, Fiona" <fiona.trahe@intel.com>, "Doherty, Declan" <declan.doherty@intel.com>, "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>, "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>, "ravi1.kumar@amd.com" <ravi1.kumar@amd.com>, "tdu@semihalf.com" <tdu@semihalf.com>, "lironh@marvell.com" <lironh@marvell.com>, "walan@marvell.com" <walan@marvell.com> Thread-Topic: [RFC] cryptodev/sym: GCM IV len != 12 byte case Thread-Index: AdTfSeDR58Xinq03QgGH1UrdmGxm2Q== Date: Wed, 20 Mar 2019 18:47:26 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B14CD9F@hasmsx109.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.104.12.183] MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Message-ID: <20190320184726.CNsdyZCaLeGYyFdiv9HMtaX7JJfNPbckdvqE1b9EfaA@z> Hi all, There is a proposition to amend a bit API due to the following lines: * - For GCM mode, this is either 12 (for 96-bit IVs) * or 16, in which case data points to J0. ... } iv; /**< Initialisation vector parameters */ Problem arise when driver cannot support J0 input, right now we know that O= PENSSL PMD works with IV instead of J0 when iv_len !=3D 12. So it may be that we have to somehow support both. There are two options, a= nd I am very curious about community opinion. 1) Add a flag to aead_xform.iv to supports IV or J0 like this: uint8_t IV_used; And this could be reflected in capabilities. Of course for 96bits IV this f= ield would not be used, so it would had to be set only for iv.length !=3D 1= 2 2) Change API comments to something like: * - For GCM mode, this is either 12 (for 96-bit IVs), * - for IV length different than 96 bits it is or J0 or IV, * - refer to specific driver rst or capabilities which one * - is supported, etc. (J0 by definition is of 16 bytes len) I cc'ing maintainers of drivers that support iv_len !=3D 16 bytes. Cannot check how it works as I have no hw. Regards, Arek