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 80DEAA0679
for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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" <arkadiuszx.kusztal@intel.com>
To: "Trahe, Fiona" <fiona.trahe@intel.com>, "dev@dpdk.org" <dev@dpdk.org>,
"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>, Michael Shamis
<michaelsh@marvell.com>
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 <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: <20190401135316.0neY1zh8IYakGcvdo4FprOaPNc8SXQgoe6qcPImonmQ@z>
Hi Fiona, Pablo,
> -----Original Message-----
> From: Trahe, Fiona
> Sent: Friday, March 29, 2019 7:03 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; akhil.goyal@nxp.com;
> ravi1.kumar@amd.com; tdu@semihalf.com; lironh@marvell.com;
> walan@marvell.com; Michael Shamis <michaelsh@marvell.com>
> Cc: Trahe, Fiona <fiona.trahe@intel.com>
> 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 <fiona.trahe@intel.com>; Doherty,
> > Declan <declan.doherty@intel.com>; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>; 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