[dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case

[dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case

[Kusztal, ArkadiuszX]

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 OPENSSL PMD works with IV instead of J0 when iv_len != 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 != 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 != 16 bytes.
Cannot check how it works as I have no hw.

Regards,
Arek

[dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case

[Kusztal, ArkadiuszX]

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 OPENSSL PMD works with IV instead of J0 when iv_len != 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 != 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 != 16 bytes.
Cannot check how it works as I have no hw.

Regards,
Arek

Re: [dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case

[Liron Himi]

+ Michael

From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
Sent: Wednesday, March 20, 2019 20:47
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; Liron Himi <lironh@marvell.com>; Alan Winkowski <walan@marvell.com>
Subject: [EXT] [RFC] cryptodev/sym: GCM IV len != 12 byte case

External Email
________________________________
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 OPENSSL PMD works with IV instead of J0 when iv_len != 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 != 12

  1.  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 != 16 bytes.
Cannot check how it works as I have no hw.

Regards,
Arek

Re: [dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case

[Liron Himi]

+ Michael

From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
Sent: Wednesday, March 20, 2019 20:47
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; Liron Himi <lironh@marvell.com>; Alan Winkowski <walan@marvell.com>
Subject: [EXT] [RFC] cryptodev/sym: GCM IV len != 12 byte case

External Email
________________________________
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 OPENSSL PMD works with IV instead of J0 when iv_len != 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 != 12

  1.  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 != 16 bytes.
Cannot check how it works as I have no hw.

Regards,
Arek

Re: [dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case

[Trahe, Fiona]

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.com; ravi1.kumar@amd.com;
> tdu@semihalf.com; lironh@marvell.com; walan@marvell.com
> Subject: [RFC] cryptodev/sym: GCM IV len != 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;   /**< 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 != 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 != 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 != 12 bytes.
> Cannot check how it works as I have no hw.
> 
> 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 special value 0 to indicate J0 format, in both capabilities and xform, i.e. 
appl passes in rte_crypto_cipher_xform.iv.length = 0
 => J0 format, already known to be 16bytes, so no need for explicit length info
appl passes in iv.length > 0
 => 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 = {
	.min = 0,
	.max = 12,
	.increment = 12
}
Capability example2: PMD can accept IV of length 12 and 16, but not J0.  
.iv_size = {
	.min = 12,
	.max = 16,
	.increment = 4
}
Capability example3: PMD can accept IV of length between 8 and 128, but not J0.  
.iv_size = {
	.min = 8,
	.max = 128,
	.increment = 1
}
Capability example4: PMD can accept IV of length between 1 and 128, and also J0.  
.iv_size = {
	.min = 0,
	.max = 128,
	.increment = 1
}
What do you think?

Re: [dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case

[Trahe, Fiona]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 2745 bytes --]

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.com; ravi1.kumar@amd.com;
> tdu@semihalf.com; lironh@marvell.com; walan@marvell.com
> Subject: [RFC] cryptodev/sym: GCM IV len != 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;   /**< 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 != 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 != 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 != 12 bytes.
> Cannot check how it works as I have no hw.
> 
> 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 special value 0 to indicate J0 format, in both capabilities and xform, i.e. 
appl passes in rte_crypto_cipher_xform.iv.length = 0
 => J0 format, already known to be 16bytes, so no need for explicit length info
appl passes in iv.length > 0
 => 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 = {
	.min = 0,
	.max = 12,
	.increment = 12
}
Capability example2: PMD can accept IV of length 12 and 16, but not J0.  
.iv_size = {
	.min = 12,
	.max = 16,
	.increment = 4
}
Capability example3: PMD can accept IV of length between 8 and 128, but not J0.  
.iv_size = {
	.min = 8,
	.max = 128,
	.increment = 1
}
Capability example4: PMD can accept IV of length between 1 and 128, and also J0.  
.iv_size = {
	.min = 0,
	.max = 128,
	.increment = 1
}
What do you think?

Re: [dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case

[Kusztal, ArkadiuszX]

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 != 12 byte case
> 
> 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.com;
> > ravi1.kumar@amd.com; tdu@semihalf.com; lironh@marvell.com;
> > walan@marvell.com
> > Subject: [RFC] cryptodev/sym: GCM IV len != 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;   /**< 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 != 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 != 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 != 12 bytes.
> > Cannot check how it works as I have no hw.
> >
> > 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 special value 0
> to indicate J0 format, in both capabilities and xform, i.e.
> appl passes in rte_crypto_cipher_xform.iv.length = 0  => J0 format, already
> known to be 16bytes, so no need for explicit length info appl passes in
> iv.length > 0  => 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 = {
> 	.min = 0,
> 	.max = 12,
> 	.increment = 12
> }
> Capability example2: PMD can accept IV of length 12 and 16, but not J0.
> .iv_size = {
> 	.min = 12,
> 	.max = 16,
> 	.increment = 4
> }
> Capability example3: PMD can accept IV of length between 8 and 128, but
> not J0.
> .iv_size = {
> 	.min = 8,
> 	.max = 128,
> 	.increment = 1
> }
> Capability example4: PMD can accept IV of length between 1 and 128, and
> also J0.
> .iv_size = {
> 	.min = 0,
> 	.max = 128,
> 	.increment = 1
> }
> What do you think?

[AK] Len(iv) == 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 driver 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 check it. So this work need to be somehow synchronized.

Regards,
Arek

Re: [dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case

[Kusztal, ArkadiuszX]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3888 bytes --]

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 != 12 byte case
> 
> 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.com;
> > ravi1.kumar@amd.com; tdu@semihalf.com; lironh@marvell.com;
> > walan@marvell.com
> > Subject: [RFC] cryptodev/sym: GCM IV len != 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;   /**< 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 != 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 != 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 != 12 bytes.
> > Cannot check how it works as I have no hw.
> >
> > 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 special value 0
> to indicate J0 format, in both capabilities and xform, i.e.
> appl passes in rte_crypto_cipher_xform.iv.length = 0  => J0 format, already
> known to be 16bytes, so no need for explicit length info appl passes in
> iv.length > 0  => 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 = {
> 	.min = 0,
> 	.max = 12,
> 	.increment = 12
> }
> Capability example2: PMD can accept IV of length 12 and 16, but not J0.
> .iv_size = {
> 	.min = 12,
> 	.max = 16,
> 	.increment = 4
> }
> Capability example3: PMD can accept IV of length between 8 and 128, but
> not J0.
> .iv_size = {
> 	.min = 8,
> 	.max = 128,
> 	.increment = 1
> }
> Capability example4: PMD can accept IV of length between 1 and 128, and
> also J0.
> .iv_size = {
> 	.min = 0,
> 	.max = 128,
> 	.increment = 1
> }
> What do you think?

[AK] Len(iv) == 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 driver 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 check it. So this work need to be somehow synchronized.

Regards,
Arek