[dpdk-dev] Crypto API for AES-XTS cipher algorithm

[dpdk-dev] Crypto API for AES-XTS cipher algorithm

[Matan Azrad]

Hi Declan, Akhil

We are going to implement mlx5 crypto PMD to support AES-XTS de\encrypt operations.

The algorithm defines block size >= 16Bytes (it is called also data-unit)which should be known for encryption\decryptions.

I didn't find this parameter    in the cypher xform.

How do you suggest to add it? maybe I'm missing something?

Matan

Re: [dpdk-dev] Crypto API for AES-XTS cipher algorithm

[Akhil Goyal]

Hi Matan,

Block size is specified in the capability structure and is expected to be same for a particular algorithm.
And for AES-XTS it is 16 bytes only if I am not wrong.

As per my understanding, data unit is different from block size.
Data unit is the input data which may or may not be multiple of block size. There are different handling of data
Unit defined if it a multiple of block size or not. And I believe there is limitation for the max value of data unit
Which the driver can give error if it does not support that particular size.

Regards,
Akhil

From: Matan Azrad <matan@nvidia.com>
Sent: Monday, January 18, 2021 8:19 PM
To: Declan Doherty <declan.doherty@intel.com>; Akhil Goyal <akhil.goyal@nxp.com>
Cc: dev@dpdk.org
Subject: Crypto API for AES-XTS cipher algorithm

Hi Declan, Akhil

We are going to implement mlx5 crypto PMD to support AES-XTS de\encrypt operations.

The algorithm defines block size >= 16Bytes (it is called also data-unit)which should be known for encryption\decryptions.

I didn't find this parameter    in the cypher xform.

How do you suggest to add it? maybe I'm missing something?

Matan

Re: [dpdk-dev] Crypto API for AES-XTS cipher algorithm

[Matan Azrad]

Hi Akhil

Yes, you right regards terms of data-unit and block size.
My intention was for data-unit.

AES-XTS algorithm is a mode of AES so by definition the block size is 16B.
So, no need capability for it.

Also in the symmetric operation structure, the `length` field is described as next:
/**< The message length, in bytes, of the source buffer
  * on which the cryptographic operation will be
  * computed. This must be a multiple of the block size
  */

It doesn't make sense to limit the user for buffer size which is multiple of 16B, one of the main reasons of AES with XTS mode is to remove this limitation of AES.

Also, the data-unit size is important parameter in AES-XTS, because encryption and decryption must use the same size of it - so the PMD cannot just guess it from the `length` field.

IMO:
Instead of block size capability it is better to use data-unit size capability.

Instead of block size limitation it is better to limit the buffer to be multiple of data-units.


It even will be good also to add this data-unit size as configuration in the transformation structure and to let the user know the supported sizes in the driver (capability or other mechanism).

What do you think?

Matan

From: Akhil Goyal <akhil.goyal@nxp.com>
Sent: Monday, January 18, 2021 5:27 PM
To: Matan Azrad <matan@nvidia.com>; Declan Doherty <declan.doherty@intel.com>
Cc: dev@dpdk.org
Subject: RE: Crypto API for AES-XTS cipher algorithm

External email: Use caution opening links or attachments

Hi Matan,

Block size is specified in the capability structure and is expected to be same for a particular algorithm.
And for AES-XTS it is 16 bytes only if I am not wrong.

As per my understanding, data unit is different from block size.
Data unit is the input data which may or may not be multiple of block size. There are different handling of data
Unit defined if it a multiple of block size or not. And I believe there is limitation for the max value of data unit
Which the driver can give error if it does not support that particular size.

Regards,
Akhil

From: Matan Azrad <matan@nvidia.com<mailto:matan@nvidia.com>>
Sent: Monday, January 18, 2021 8:19 PM
To: Declan Doherty <declan.doherty@intel.com<mailto:declan.doherty@intel.com>>; Akhil Goyal <akhil.goyal@nxp.com<mailto:akhil.goyal@nxp.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>
Subject: Crypto API for AES-XTS cipher algorithm

Hi Declan, Akhil

We are going to implement mlx5 crypto PMD to support AES-XTS de\encrypt operations.

The algorithm defines block size >= 16Bytes (it is called also data-unit)which should be known for encryption\decryptions.

I didn't find this parameter    in the cypher xform.

How do you suggest to add it? maybe I'm missing something?

Matan

Re: [dpdk-dev] Crypto API for AES-XTS cipher algorithm

[Akhil Goyal]

Hi Matan,

Can you send an RFC patch for the changes you are looking forward in the cryptodev lib.

Regards,
Akhil

From: Matan Azrad <matan@nvidia.com>
Sent: Thursday, January 21, 2021 11:16 PM
To: Akhil Goyal <akhil.goyal@nxp.com>; Declan Doherty <declan.doherty@intel.com>
Cc: dev@dpdk.org
Subject: RE: Crypto API for AES-XTS cipher algorithm

Hi Akhil

Yes, you right regards terms of data-unit and block size.
My intention was for data-unit.

AES-XTS algorithm is a mode of AES so by definition the block size is 16B.
So, no need capability for it.

Also in the symmetric operation structure, the `length` field is described as next:
/**< The message length, in bytes, of the source buffer
  * on which the cryptographic operation will be
  * computed. This must be a multiple of the block size
  */

It doesn't make sense to limit the user for buffer size which is multiple of 16B, one of the main reasons of AES with XTS mode is to remove this limitation of AES.

Also, the data-unit size is important parameter in AES-XTS, because encryption and decryption must use the same size of it - so the PMD cannot just guess it from the `length` field.


IMO:
Instead of block size capability it is better to use data-unit size capability.

Instead of block size limitation it is better to limit the buffer to be multiple of data-units.


It even will be good also to add this data-unit size as configuration in the transformation structure and to let the user know the supported sizes in the driver (capability or other mechanism).

What do you think?

Matan

From: Akhil Goyal <akhil.goyal@nxp.com<mailto:akhil.goyal@nxp.com>>
Sent: Monday, January 18, 2021 5:27 PM
To: Matan Azrad <matan@nvidia.com<mailto:matan@nvidia.com>>; Declan Doherty <declan.doherty@intel.com<mailto:declan.doherty@intel.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>
Subject: RE: Crypto API for AES-XTS cipher algorithm

External email: Use caution opening links or attachments

Hi Matan,

Block size is specified in the capability structure and is expected to be same for a particular algorithm.
And for AES-XTS it is 16 bytes only if I am not wrong.

As per my understanding, data unit is different from block size.
Data unit is the input data which may or may not be multiple of block size. There are different handling of data
Unit defined if it a multiple of block size or not. And I believe there is limitation for the max value of data unit
Which the driver can give error if it does not support that particular size.

Regards,
Akhil

From: Matan Azrad <matan@nvidia.com<mailto:matan@nvidia.com>>
Sent: Monday, January 18, 2021 8:19 PM
To: Declan Doherty <declan.doherty@intel.com<mailto:declan.doherty@intel.com>>; Akhil Goyal <akhil.goyal@nxp.com<mailto:akhil.goyal@nxp.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>
Subject: Crypto API for AES-XTS cipher algorithm

Hi Declan, Akhil

We are going to implement mlx5 crypto PMD to support AES-XTS de\encrypt operations.

The algorithm defines block size >= 16Bytes (it is called also data-unit)which should be known for encryption\decryptions.

I didn't find this parameter    in the cypher xform.

How do you suggest to add it? maybe I'm missing something?

Matan

Re: [dpdk-dev] Crypto API for AES-XTS cipher algorithm

[Matan Azrad]

Yes. I'll do soon.

From: Akhil Goyal <akhil.goyal@nxp.com>
Sent: Thursday, January 21, 2021 8:33 PM
To: Matan Azrad <matan@nvidia.com>; Declan Doherty <declan.doherty@intel.com>
Cc: dev@dpdk.org
Subject: RE: Crypto API for AES-XTS cipher algorithm

External email: Use caution opening links or attachments

Hi Matan,

Can you send an RFC patch for the changes you are looking forward in the cryptodev lib.

Regards,
Akhil

From: Matan Azrad <matan@nvidia.com<mailto:matan@nvidia.com>>
Sent: Thursday, January 21, 2021 11:16 PM
To: Akhil Goyal <akhil.goyal@nxp.com<mailto:akhil.goyal@nxp.com>>; Declan Doherty <declan.doherty@intel.com<mailto:declan.doherty@intel.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>
Subject: RE: Crypto API for AES-XTS cipher algorithm

Hi Akhil

Yes, you right regards terms of data-unit and block size.
My intention was for data-unit.

AES-XTS algorithm is a mode of AES so by definition the block size is 16B.
So, no need capability for it.

Also in the symmetric operation structure, the `length` field is described as next:
/**< The message length, in bytes, of the source buffer
  * on which the cryptographic operation will be
  * computed. This must be a multiple of the block size
  */

It doesn't make sense to limit the user for buffer size which is multiple of 16B, one of the main reasons of AES with XTS mode is to remove this limitation of AES.

Also, the data-unit size is important parameter in AES-XTS, because encryption and decryption must use the same size of it - so the PMD cannot just guess it from the `length` field.


IMO:
Instead of block size capability it is better to use data-unit size capability.

Instead of block size limitation it is better to limit the buffer to be multiple of data-units.


It even will be good also to add this data-unit size as configuration in the transformation structure and to let the user know the supported sizes in the driver (capability or other mechanism).

What do you think?

Matan

From: Akhil Goyal <akhil.goyal@nxp.com<mailto:akhil.goyal@nxp.com>>
Sent: Monday, January 18, 2021 5:27 PM
To: Matan Azrad <matan@nvidia.com<mailto:matan@nvidia.com>>; Declan Doherty <declan.doherty@intel.com<mailto:declan.doherty@intel.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>
Subject: RE: Crypto API for AES-XTS cipher algorithm

External email: Use caution opening links or attachments

Hi Matan,

Block size is specified in the capability structure and is expected to be same for a particular algorithm.
And for AES-XTS it is 16 bytes only if I am not wrong.

As per my understanding, data unit is different from block size.
Data unit is the input data which may or may not be multiple of block size. There are different handling of data
Unit defined if it a multiple of block size or not. And I believe there is limitation for the max value of data unit
Which the driver can give error if it does not support that particular size.

Regards,
Akhil

From: Matan Azrad <matan@nvidia.com<mailto:matan@nvidia.com>>
Sent: Monday, January 18, 2021 8:19 PM
To: Declan Doherty <declan.doherty@intel.com<mailto:declan.doherty@intel.com>>; Akhil Goyal <akhil.goyal@nxp.com<mailto:akhil.goyal@nxp.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>
Subject: Crypto API for AES-XTS cipher algorithm

Hi Declan, Akhil

We are going to implement mlx5 crypto PMD to support AES-XTS de\encrypt operations.

The algorithm defines block size >= 16Bytes (it is called also data-unit)which should be known for encryption\decryptions.

I didn't find this parameter    in the cypher xform.

How do you suggest to add it? maybe I'm missing something?

Matan