DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Crypto API for AES-XTS cipher algorithm
@ 2021-01-18 14:48 Matan Azrad
  2021-01-18 15:27 ` Akhil Goyal
  0 siblings, 1 reply; 5+ messages in thread
From: Matan Azrad @ 2021-01-18 14:48 UTC (permalink / raw)
  To: Declan Doherty, Akhil Goyal; +Cc: dev

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Crypto API for AES-XTS cipher algorithm
  2021-01-18 14:48 [dpdk-dev] Crypto API for AES-XTS cipher algorithm Matan Azrad
@ 2021-01-18 15:27 ` Akhil Goyal
  2021-01-21 17:45   ` Matan Azrad
  0 siblings, 1 reply; 5+ messages in thread
From: Akhil Goyal @ 2021-01-18 15:27 UTC (permalink / raw)
  To: Matan Azrad, Declan Doherty; +Cc: dev

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Crypto API for AES-XTS cipher algorithm
  2021-01-18 15:27 ` Akhil Goyal
@ 2021-01-21 17:45   ` Matan Azrad
  2021-01-21 18:33     ` Akhil Goyal
  0 siblings, 1 reply; 5+ messages in thread
From: Matan Azrad @ 2021-01-21 17:45 UTC (permalink / raw)
  To: Akhil Goyal, Declan Doherty; +Cc: dev

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Crypto API for AES-XTS cipher algorithm
  2021-01-21 17:45   ` Matan Azrad
@ 2021-01-21 18:33     ` Akhil Goyal
  2021-02-02 14:10       ` Matan Azrad
  0 siblings, 1 reply; 5+ messages in thread
From: Akhil Goyal @ 2021-01-21 18:33 UTC (permalink / raw)
  To: Matan Azrad, Declan Doherty; +Cc: dev

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Crypto API for AES-XTS cipher algorithm
  2021-01-21 18:33     ` Akhil Goyal
@ 2021-02-02 14:10       ` Matan Azrad
  0 siblings, 0 replies; 5+ messages in thread
From: Matan Azrad @ 2021-02-02 14:10 UTC (permalink / raw)
  To: Akhil Goyal, Declan Doherty; +Cc: dev

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-02-02 14:11 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-18 14:48 [dpdk-dev] Crypto API for AES-XTS cipher algorithm Matan Azrad
2021-01-18 15:27 ` Akhil Goyal
2021-01-21 17:45   ` Matan Azrad
2021-01-21 18:33     ` Akhil Goyal
2021-02-02 14:10       ` Matan Azrad

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git