From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 80DEAA0679 for ; Mon, 1 Apr 2019 15:53:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 29E1234F3; Mon, 1 Apr 2019 15:53:22 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id A074B343C for ; Mon, 1 Apr 2019 15:53:20 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2019 06:53:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,296,1549958400"; d="scan'208";a="160289511" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga001.fm.intel.com with ESMTP; 01 Apr 2019 06:53:19 -0700 Received: from lcsmsx155.ger.corp.intel.com (10.186.165.233) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 1 Apr 2019 06:53:19 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.144]) by LCSMSX155.ger.corp.intel.com ([169.254.12.205]) with mapi id 14.03.0415.000; Mon, 1 Apr 2019 16:53:17 +0300 From: "Kusztal, ArkadiuszX" To: "Trahe, Fiona" , "dev@dpdk.org" , "Doherty, Declan" , "De Lara Guarch, Pablo" , "akhil.goyal@nxp.com" , "ravi1.kumar@amd.com" , "tdu@semihalf.com" , "lironh@marvell.com" , "walan@marvell.com" , Michael Shamis Thread-Topic: [RFC] cryptodev/sym: GCM IV len != 12 byte case Thread-Index: AdTfSeDR58Xinq03QgGH1UrdmGxm2QHD0+/gAIyY3eA= Date: Mon, 1 Apr 2019 13:53:16 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B14EF77@hasmsx109.ger.corp.intel.com> References: <06EE24DD0B19E248B53F6DC8657831551B14CD9F@hasmsx109.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B4358972374E@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B4358972374E@IRSMSX101.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.116.174] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190401135316.0neY1zh8IYakGcvdo4FprOaPNc8SXQgoe6qcPImonmQ@z> Hi Fiona, Pablo, > -----Original Message----- > From: Trahe, Fiona > Sent: Friday, March 29, 2019 7:03 PM > To: Kusztal, ArkadiuszX ; dev@dpdk.org; > Doherty, Declan ; De Lara Guarch, Pablo > ; akhil.goyal@nxp.com; > ravi1.kumar@amd.com; tdu@semihalf.com; lironh@marvell.com; > walan@marvell.com; Michael Shamis > Cc: Trahe, Fiona > Subject: RE: [RFC] cryptodev/sym: GCM IV len !=3D 12 byte case >=20 > Hi Arek, >=20 > > -----Original Message----- > > From: Kusztal, ArkadiuszX > > Sent: Wednesday, March 20, 2019 6:47 PM > > To: dev@dpdk.org; Trahe, Fiona ; Doherty, > > Declan ; De Lara Guarch, Pablo > > ; akhil.goyal@nxp.com; > > ravi1.kumar@amd.com; tdu@semihalf.com; lironh@marvell.com; > > walan@marvell.com > > Subject: [RFC] cryptodev/sym: GCM IV len !=3D 12 byte case > > > > 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;=A0=A0 /**< Initialisation vector parameters */ > > > > > > Problem arise when driver cannot support J0 input, right now we know > > that OPENSSL 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, and 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 field would not be used, so it would had to be set only for > > iv.length !=3D 12 > > 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 12 bytes. > > Cannot check how it works as I have no hw. > > > > Regards, > > Arek >=20 > [Fiona] Pablo suggested a simpler approach. Same functional change in API= - > i.e. support input in both J0 and IV formats, but different implementatio= n, no > need for new flags in session or capabilities. Proposal is to use special= value 0 > to indicate J0 format, in both capabilities and xform, i.e. > appl passes in rte_crypto_cipher_xform.iv.length =3D 0 =3D> J0 format, a= lready > known to be 16bytes, so no need for explicit length info appl passes in > iv.length > 0 =3D> IV, so PMD must derive J0. (current API, no change he= re) >=20 > Capability example1: PMD can accept a 16-byte J0 OR a 12 byte IV .iv_size= =3D { > .min =3D 0, > .max =3D 12, > .increment =3D 12 > } > Capability example2: PMD can accept IV of length 12 and 16, but not J0. > .iv_size =3D { > .min =3D 12, > .max =3D 16, > .increment =3D 4 > } > Capability example3: PMD can accept IV of length between 8 and 128, but > not J0. > .iv_size =3D { > .min =3D 8, > .max =3D 128, > .increment =3D 1 > } > Capability example4: PMD can accept IV of length between 1 and 128, and > also J0. > .iv_size =3D { > .min =3D 0, > .max =3D 128, > .increment =3D 1 > } > What do you think? [AK] Len(iv) =3D=3D 0 is invalid per GCM spec so its fine for me, although = it is very unlikely case that driver would support both iv and J0. [AK] Only one issue in this proposal and first one I proposed is that the d= river which properly implements API directives need to be reworked, and we = don't know which driver properly implements it as we have no hardware to ch= eck it. So this work need to be somehow synchronized. Regards, Arek