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 406EEA05D3
for <public@inbox.dpdk.org>; Fri, 29 Mar 2019 19:02:54 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 7BE48343C;
Fri, 29 Mar 2019 19:02:53 +0100 (CET)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151])
by dpdk.org (Postfix) with ESMTP id 613BE1B05
for <dev@dpdk.org>; Fri, 29 Mar 2019 19:02:51 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga001.jf.intel.com ([10.7.209.18])
by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
29 Mar 2019 11:02:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.60,285,1549958400"; d="scan'208";a="218819051"
Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66])
by orsmga001.jf.intel.com with ESMTP; 29 Mar 2019 11:02:40 -0700
Received: from irsmsx101.ger.corp.intel.com ([169.254.1.230]) by
IRSMSX152.ger.corp.intel.com ([169.254.6.139]) with mapi id 14.03.0415.000;
Fri, 29 Mar 2019 18:02:39 +0000
From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@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>
CC: "Trahe, Fiona" <fiona.trahe@intel.com>
Thread-Topic: [RFC] cryptodev/sym: GCM IV len != 12 byte case
Thread-Index: AdTfSeDR58Xinq03QgGH1UrdmGxm2QHD0+/g
Date: Fri, 29 Mar 2019 18:02:38 +0000
Message-ID:
<348A99DA5F5B7549AA880327E580B4358972374E@IRSMSX101.ger.corp.intel.com>
References: <06EE24DD0B19E248B53F6DC8657831551B14CD9F@hasmsx109.ger.corp.intel.com>
In-Reply-To: <06EE24DD0B19E248B53F6DC8657831551B14CD9F@hasmsx109.ger.corp.intel.com>
Accept-Language: en-IE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTlmZDNhOWUtMjgzZi00NGMxLWE4YmQtMmI1MDc1NGQwY2YyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYllyUmx2YitRVTdUREJ2TEVHb0dJcERaWDJIQ1o0SE4yYXNqNWFDWHZIYnZBMUtDU3pVSW9oYUl2UmpZa0JGUyJ9
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [163.33.239.181]
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: <20190329180238.lsBoaymREdPjDZFNBAiYQWZrx77sxB6dpK2wMOJLdhY@z>
Hi Arek,
> -----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.c=
om; ravi1.kumar@amd.com;
> tdu@semihalf.com; lironh@marvell.com; walan@marvell.com
> Subject: [RFC] cryptodev/sym: GCM IV len !=3D 12 byte case
>=20
> Hi all,
>=20
> There is a proposition to amend a bit API due to the following lines:
>=20
> * - 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 */
>=20
>=20
> 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.
>=20
> 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)
>=20
> I cc'ing maintainers of drivers that support iv_len !=3D 12 bytes.
> Cannot check how it works as I have no hw.
>=20
> Regards,
> Arek
[Fiona] Pablo suggested a simpler approach. Same functional change in API -=
i.e. support input in both J0 and IV formats, but different implementation=
, no need for new flags in session or capabilities. Proposal is to use spec=
ial value 0 to indicate J0 format, in both capabilities and xform, i.e.=20
appl passes in rte_crypto_cipher_xform.iv.length =3D 0
=3D> J0 format, already known to be 16bytes, so no need for explicit lengt=
h info
appl passes in iv.length > 0
=3D> IV, so PMD must derive J0. (current API, no change here)
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. =20
.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. =20
.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 als=
o J0. =20
.iv_size =3D {
.min =3D 0,
.max =3D 128,
.increment =3D 1
}
What do you think?