Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.

Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.

[Dybkowski, AdamX]

Hi Naveen.

Regarding your message sent to dpdk-users mailing list:
https://mails.dpdk.org/archives/users/2019-September/004382.html

We've tested here at Intel the digest-encrypted combination you wrote about, with auth.algo = AES-CMAC and cipher.algo = AES-CTR, and it seems everything works fine.
Do you set the length fields properly when creating the operation? According to the header file rte_crypto_sym.h, in the structure rte_crypto_sym_op, the field cipher.data.length should be written in bits for the SNOW 3G, KASUMI and ZUC ciphers, and in bytes for other.

Have a look what the header file says:

uint32_t length;
/**< 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
  * if a block cipher is being used. This is
  * also the same as the result length.
  *
  * @note
  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
  * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
  * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
  * this field should be in bits.
  */

This also gets built into the documentation available here:
https://doc.dpdk.org/api-19.08/structrte__crypto__sym__op.html#aebb70c2aab3407a9f05334c47131a43b

Maybe that's why SNOW3G and ZUC were working for you, while AES-CTR did not?
The same applies to the offset field and to digest.data.offset and digest.data.length fields.

Please verify in your code how you set these all offset and length fields and check if you write the number of bits or the number of bytes in them.

Adam

Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.

[Naveen Kumar]

Hi Adam,
I configured the lengths as mentioned in comment you pointed and verified it carefully.
Is the test suite with digest-encrypted combination you tested available in public?
Can you share the QAT device information (hardware, firmware versions etc) you used?

Note:
I have done some experiments to conclude the overwriting issue:
     Configured “auth_xform->auth.digest_length = 4” and expecting 4 bytes of CMAC. Digest data location is configured immediately after data.
     Just for experiment purpose, I increased the length by 4 bytes more than the actual data length to be ciphered (on top of data_length + digest_length).
    The sample result is as below, where “raw” digest overwritten on the highlighted location. (It also confirms my data length configuration is intact)

00000090: 00 00 00 00 00 00 00 00 87 4D 61 91 B6 20 E3 26 | .........Ma.. .&
000000A0: 1B EF 68 64 99 0D B6 CE 98 06 F6 6B 79 70 FD FF | ..hd.......kyp..
000000B0: 86 17 18 7B B9 FF FD FF 5A E4 DF 3E DB D5 D3 5E | ...{....Z..>...^
000000C0: 5B 4F 09 02 0D B0 3E AB 1E 03 1D DA 2F BE 03 D1 | [O....>...../...
000000D0: 79 21 70 A0 F3 00 9C EE "E8 1E 96 D6" 14 8A 91 0E | y!p.............

Regards,
Naveen

--
Naveen Kumar
Senior Engineer

CommAgility is a http://wirelesstelecomgroup.com/ company
T: +49 (0)203 306 4537 | http://www.commagility.com
Registered in England, Company No. 05914025. VAT No. DE299686390
CommAgility is an ISO 9001:2015-certified company
This email is confidential, for recipient’s use only.

--
Naveen Kumar
Senior Engineer

CommAgility is a Wireless Telecom Group company
T: +49 (0)203 306 4537 | www.commagility.com
Registered in England, Company No. 05914025. VAT No. DE299686390
CommAgility is an ISO 9001:2015-certified company
This email is confidential, for recipient’s use only.
From: Dybkowski, AdamX <mailto:adamx.dybkowski@intel.com>
Sent: Wednesday, October 16, 2019 2:49 PM
To: mailto:users@dpdk.org; Naveen Kumar <mailto:Naveen.Kumar@commagility.com>
Cc: Trahe, Fiona <mailto:fiona.trahe@intel.com>
Subject: Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.

Hi Naveen.

Regarding your message sent to dpdk-users mailing list:
https://mails.dpdk.org/archives/users/2019-September/004382.html

We’ve tested here at Intel the digest-encrypted combination you wrote about, with auth.algo = AES-CMAC and cipher.algo = AES-CTR, and it seems everything works fine.
Do you set the length fields properly when creating the operation? According to the header file rte_crypto_sym.h, in the structure rte_crypto_sym_op, the field cipher.data.length should be written in bits for the SNOW 3G, KASUMI and ZUC ciphers, and in bytes for other.

Have a look what the header file says:

uint32_t length;
/**< 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
  * if a block cipher is being used. This is
  * also the same as the result length.
  *
  * @note
  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
  * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
  * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
  * this field should be in bits.
  */

This also gets built into the documentation available here:
https://doc.dpdk.org/api-19.08/structrte__crypto__sym__op.html#aebb70c2aab3407a9f05334c47131a43b

Maybe that’s why SNOW3G and ZUC were working for you, while AES-CTR did not?
The same applies to the offset field and to digest.data.offset and digest.data.length fields.

Please verify in your code how you set these all offset and length fields and check if you write the number of bits or the number of bytes in them.

Adam

Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.

[Dybkowski, AdamX]

Hi Naveen.

The unit tests for AES-CTR + AES CMAC was posted today to dev@dpdk.org
I also added you in CC.

I hope this helps.

Best regards,

Adam Dybkowski

> -----Original Message-----
> From: Naveen Kumar [mailto:Naveen.Kumar@commagility.com]
> Sent: Thursday, 17 October, 2019 17:30
> To: Dybkowski, AdamX <adamx.dybkowski@intel.com>; users@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [dpdk-users] AES "Digest-encrypted" crypto chain case.
> 
> Hi Adam,
> I configured the lengths as mentioned in comment you pointed and verified it
> carefully.
> Is the test suite with digest-encrypted combination you tested available in
> public?
> Can you share the QAT device information (hardware, firmware versions etc)
> you used?
> 
> Note:
> I have done some experiments to conclude the overwriting issue:
>      Configured “auth_xform->auth.digest_length = 4” and expecting 4 bytes of
> CMAC. Digest data location is configured immediately after data.
>      Just for experiment purpose, I increased the length by 4 bytes more than
> the actual data length to be ciphered (on top of data_length + digest_length).
>     The sample result is as below, where “raw” digest overwritten on the
> highlighted location. (It also confirms my data length configuration is intact)
> 
> 00000090: 00 00 00 00 00 00 00 00 87 4D 61 91 B6 20 E3 26 | .........Ma.. .&
> 000000A0: 1B EF 68 64 99 0D B6 CE 98 06 F6 6B 79 70 FD FF | ..hd.......kyp..
> 000000B0: 86 17 18 7B B9 FF FD FF 5A E4 DF 3E DB D5 D3 5E | ...{....Z..>...^
> 000000C0: 5B 4F 09 02 0D B0 3E AB 1E 03 1D DA 2F BE 03 D1 | [O....>...../...
> 000000D0: 79 21 70 A0 F3 00 9C EE "E8 1E 96 D6" 14 8A 91 0E | y!p.............
> 
> Regards,
> Naveen
> 
> --
> Naveen Kumar
> Senior Engineer
> 
> CommAgility is a http://wirelesstelecomgroup.com/ company
> T: +49 (0)203 306 4537 | http://www.commagility.com Registered in England,
> Company No. 05914025. VAT No. DE299686390 CommAgility is an ISO
> 9001:2015-certified company This email is confidential, for recipient’s use
> only.
> 
> --
> Naveen Kumar
> Senior Engineer
> 
> CommAgility is a Wireless Telecom Group company
> T: +49 (0)203 306 4537 | www.commagility.com Registered in England,
> Company No. 05914025. VAT No. DE299686390 CommAgility is an ISO
> 9001:2015-certified company This email is confidential, for recipient’s use
> only.
> From: Dybkowski, AdamX <mailto:adamx.dybkowski@intel.com>
> Sent: Wednesday, October 16, 2019 2:49 PM
> To: mailto:users@dpdk.org; Naveen Kumar
> <mailto:Naveen.Kumar@commagility.com>
> Cc: Trahe, Fiona <mailto:fiona.trahe@intel.com>
> Subject: Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.
> 
> Hi Naveen.
> 
> Regarding your message sent to dpdk-users mailing list:
> https://mails.dpdk.org/archives/users/2019-September/004382.html
> 
> We’ve tested here at Intel the digest-encrypted combination you wrote
> about, with auth.algo = AES-CMAC and cipher.algo = AES-CTR, and it seems
> everything works fine.
> Do you set the length fields properly when creating the operation? According
> to the header file rte_crypto_sym.h, in the structure rte_crypto_sym_op, the
> field cipher.data.length should be written in bits for the SNOW 3G, KASUMI
> and ZUC ciphers, and in bytes for other.
> 
> Have a look what the header file says:
> 
> uint32_t length;
> /**< 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
>   * if a block cipher is being used. This is
>   * also the same as the result length.
>   *
>   * @note
>   * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
>   * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
>   * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
>   * this field should be in bits.
>   */
> 
> This also gets built into the documentation available here:
> https://doc.dpdk.org/api-
> 19.08/structrte__crypto__sym__op.html#aebb70c2aab3407a9f05334c47131
> a43b
> 
> Maybe that’s why SNOW3G and ZUC were working for you, while AES-CTR
> did not?
> The same applies to the offset field and to digest.data.offset and
> digest.data.length fields.
> 
> Please verify in your code how you set these all offset and length fields and
> check if you write the number of bits or the number of bytes in them.
> 
> Adam

Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.

[Naveen Kumar]

Hi Adam,

The combination works now as expected. The issue was because of using 19.05 tag. Seems a fix went in after that.
After updating to current master, I could get the aes-cmac+ aes-ctr combination working as expected in my project.
Previously, I verified successfully your unit test patch as well to rule out any hardware glitch.

Thanks


--
Naveen Kumar
Senior Engineer

CommAgility is a Wireless Telecom Group company
T: +49 (0)203 306 4537 | www.commagility.com
Registered in England, Company No. 05914025. VAT No. DE299686390
CommAgility is an ISO 9001:2015-certified company
This email is confidential, for recipient’s use only.
-----Original Message-----
From: Dybkowski, AdamX <adamx.dybkowski@intel.com>
Sent: Friday, October 18, 2019 3:20 PM
To: Naveen Kumar <Naveen.Kumar@commagility.com>; users@dpdk.org
Cc: Trahe, Fiona <fiona.trahe@intel.com>
Subject: RE: [dpdk-users] AES "Digest-encrypted" crypto chain case.

Hi Naveen.

The unit tests for AES-CTR + AES CMAC was posted today to dev@dpdk.org I also added you in CC.

I hope this helps.

Best regards,

Adam Dybkowski

> -----Original Message-----
> From: Naveen Kumar [mailto:Naveen.Kumar@commagility.com]
> Sent: Thursday, 17 October, 2019 17:30
> To: Dybkowski, AdamX <adamx.dybkowski@intel.com>; users@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [dpdk-users] AES "Digest-encrypted" crypto chain case.
>
> Hi Adam,
> I configured the lengths as mentioned in comment you pointed and
> verified it carefully.
> Is the test suite with digest-encrypted combination you tested
> available in public?
> Can you share the QAT device information (hardware, firmware versions
> etc) you used?
>
> Note:
> I have done some experiments to conclude the overwriting issue:
>      Configured “auth_xform->auth.digest_length = 4” and expecting 4
> bytes of CMAC. Digest data location is configured immediately after data.
>      Just for experiment purpose, I increased the length by 4 bytes
> more than the actual data length to be ciphered (on top of data_length + digest_length).
>     The sample result is as below, where “raw” digest overwritten on
> the highlighted location. (It also confirms my data length
> configuration is intact)
>
> 00000090: 00 00 00 00 00 00 00 00 87 4D 61 91 B6 20 E3 26 |
> .........Ma.. .&
> 000000A0: 1B EF 68 64 99 0D B6 CE 98 06 F6 6B 79 70 FD FF | ..hd.......kyp..
> 000000B0: 86 17 18 7B B9 FF FD FF 5A E4 DF 3E DB D5 D3 5E |
> ...{....Z..>...^
> 000000C0: 5B 4F 09 02 0D B0 3E AB 1E 03 1D DA 2F BE 03 D1 | [O....>...../...
> 000000D0: 79 21 70 A0 F3 00 9C EE "E8 1E 96 D6" 14 8A 91 0E | y!p.............
>
> Regards,
> Naveen
>
> --
> Naveen Kumar
> Senior Engineer
>
> CommAgility is a http://wirelesstelecomgroup.com/ company
> T: +49 (0)203 306 4537 | http://www.commagility.com Registered in
> England, Company No. 05914025. VAT No. DE299686390 CommAgility is an
> ISO 9001:2015-certified company This email is confidential, for
> recipient’s use only.
>
> --
> Naveen Kumar
> Senior Engineer
>
> CommAgility is a Wireless Telecom Group company
> T: +49 (0)203 306 4537 | www.commagility.com Registered in England,
> Company No. 05914025. VAT No. DE299686390 CommAgility is an ISO
> 9001:2015-certified company This email is confidential, for
> recipient’s use only.
> From: Dybkowski, AdamX <mailto:adamx.dybkowski@intel.com>
> Sent: Wednesday, October 16, 2019 2:49 PM
> To: mailto:users@dpdk.org; Naveen Kumar
> <mailto:Naveen.Kumar@commagility.com>
> Cc: Trahe, Fiona <mailto:fiona.trahe@intel.com>
> Subject: Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.
>
> Hi Naveen.
>
> Regarding your message sent to dpdk-users mailing list:
> https://mails.dpdk.org/archives/users/2019-September/004382.html
>
> We’ve tested here at Intel the digest-encrypted combination you wrote
> about, with auth.algo = AES-CMAC and cipher.algo = AES-CTR, and it
> seems everything works fine.
> Do you set the length fields properly when creating the operation?
> According to the header file rte_crypto_sym.h, in the structure
> rte_crypto_sym_op, the field cipher.data.length should be written in
> bits for the SNOW 3G, KASUMI and ZUC ciphers, and in bytes for other.
>
> Have a look what the header file says:
>
> uint32_t length;
> /**< 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
>   * if a block cipher is being used. This is
>   * also the same as the result length.
>   *
>   * @note
>   * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
>   * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
>   * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
>   * this field should be in bits.
>   */
>
> This also gets built into the documentation available here:
> https://doc.dpdk.org/api-
> 19.08/structrte__crypto__sym__op.html#aebb70c2aab3407a9f05334c47131
> a43b
>
> Maybe that’s why SNOW3G and ZUC were working for you, while AES-CTR
> did not?
> The same applies to the offset field and to digest.data.offset and
> digest.data.length fields.
>
> Please verify in your code how you set these all offset and length
> fields and check if you write the number of bits or the number of bytes in them.
>
> Adam

[dpdk-users] AES "Digest-encrypted" crypto chain case.

[Naveen Kumar]

Hi All,
I am trying to test AES symmetric crypto case  "Digest-encrypted" by chaining Authentication operation followed by Ciphering.
Digest data pointer, Ciphering lengths etc., are configured such that ciphering operation includes the digest data (as mentioned in ‘rte_crypto_sym.h’ line:650-715).

With QAT PMD, I see the ‘raw’ digest data overwritten on the ciphered output as end result.

This issue is seen only with AES - ‘Digest-Encrypt’ chained operation. Not with Snow3G/ZUC chained operations.

Does anyone face this issue?

Regards,
Naveen

--
Naveen Kumar
Senior Engineer

CommAgility is a Wireless Telecom Group company
T: +49 (0)203 306 4537 | www.commagility.com
Registered in England, Company No. 05914025. VAT No. DE299686390
CommAgility is an ISO 9001:2015-certified company
This email is confidential, for recipient’s use only.

Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.

[Trahe, Fiona]

Hi Naveen,

Which chain exactly are you testing? i.e. which cipher mode, which auth algorithm?
Our tests so far have focussed on ZUC and Snow3G use-cases.

Fiona

> -----Original Message-----
> From: users [mailto:users-bounces@dpdk.org] On Behalf Of Naveen Kumar
> Sent: Monday, September 9, 2019 10:16 AM
> To: users@dpdk.org
> Subject: [dpdk-users] AES "Digest-encrypted" crypto chain case.
> 
> Hi All,
> I am trying to test AES symmetric crypto case  "Digest-encrypted" by chaining Authentication operation
> followed by Ciphering.
> Digest data pointer, Ciphering lengths etc., are configured such that ciphering operation includes the
> digest data (as mentioned in ‘rte_crypto_sym.h’ line:650-715).
> 
> With QAT PMD, I see the ‘raw’ digest data overwritten on the ciphered output as end result.
> 
> This issue is seen only with AES - ‘Digest-Encrypt’ chained operation. Not with Snow3G/ZUC chained
> operations.
> 
> Does anyone face this issue?
> 
> Regards,
> Naveen
> 
> --
> Naveen Kumar
> Senior Engineer
> 
> CommAgility is a Wireless Telecom Group company
> T: +49 (0)203 306 4537 | www.commagility.com
> Registered in England, Company No. 05914025. VAT No. DE299686390
> CommAgility is an ISO 9001:2015-certified company
> This email is confidential, for recipient’s use only.

Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.

[Naveen Kumar]

Hi Fiona,
Thanks for prompt response.
I observe digest overwriting issue with below combination (chained):

//
    auth_xform->type = RTE_CRYPTO_SYM_XFORM_AUTH;
    auth_xform->auth.algo = RTE_CRYPTO_AUTH_AES_CMAC;
    auth_xform->auth.op = RTE_CRYPTO_AUTH_OP_GENERATE;

    cipher_xform->type = RTE_CRYPTO_SYM_XFORM_CIPHER;
    cipher_xform->cipher.algo = RTE_CRYPTO_CIPHER_AES_CTR;
    cipher_xform->cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
//

Testing with snow3g and ZUC on same test suite i.e, encryption including digest, works as expected.

regards,
Naveen


--
Naveen Kumar
Senior Engineer

CommAgility is a Wireless Telecom Group company
T: +49 (0)203 306 4537 | www.commagility.com
Registered in England, Company No. 05914025. VAT No. DE299686390
CommAgility is an ISO 9001:2015-certified company
This email is confidential, for recipient’s use only.
-----Original Message-----
From: Trahe, Fiona <fiona.trahe@intel.com>
Sent: Monday, September 9, 2019 4:09 PM
To: Naveen Kumar <Naveen.Kumar@commagility.com>; users@dpdk.org
Cc: Trahe, Fiona <fiona.trahe@intel.com>
Subject: RE: [dpdk-users] AES "Digest-encrypted" crypto chain case.

Hi Naveen,

Which chain exactly are you testing? i.e. which cipher mode, which auth algorithm?
Our tests so far have focussed on ZUC and Snow3G use-cases.

Fiona

> -----Original Message-----
> From: users [mailto:users-bounces@dpdk.org] On Behalf Of Naveen Kumar
> Sent: Monday, September 9, 2019 10:16 AM
> To: users@dpdk.org
> Subject: [dpdk-users] AES "Digest-encrypted" crypto chain case.
>
> Hi All,
> I am trying to test AES symmetric crypto case  "Digest-encrypted" by
> chaining Authentication operation followed by Ciphering.
> Digest data pointer, Ciphering lengths etc., are configured such that
> ciphering operation includes the digest data (as mentioned in ‘rte_crypto_sym.h’ line:650-715).
>
> With QAT PMD, I see the ‘raw’ digest data overwritten on the ciphered output as end result.
>
> This issue is seen only with AES - ‘Digest-Encrypt’ chained operation.
> Not with Snow3G/ZUC chained operations.
>
> Does anyone face this issue?
>
> Regards,
> Naveen
>
> --
> Naveen Kumar
> Senior Engineer
>
> CommAgility is a Wireless Telecom Group company
> T: +49 (0)203 306 4537 | www.commagility.com Registered in England,
> Company No. 05914025. VAT No. DE299686390 CommAgility is an ISO
> 9001:2015-certified company This email is confidential, for
> recipient’s use only.