From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 613BE1B05 for ; 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" 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" 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="iso-8859-1" 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: , X-List-Received-Date: Fri, 29 Mar 2019 18:02:52 -0000 Hi Arek, > -----Original Message----- > From: Kusztal, ArkadiuszX > Sent: Wednesday, March 20, 2019 6:47 PM > To: dev@dpdk.org; Trahe, Fiona ; Doherty, Declan <= declan.doherty@intel.com>; > De Lara Guarch, Pablo ; 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? 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 406EEA05D3 for ; 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 ; 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" 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 ; Doherty, Declan <= declan.doherty@intel.com>; > De Lara Guarch, Pablo ; 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?