Hi Naveen. The unit tests for AES-CTR + AES CMAC was posted today to [email protected] I also added you in CC.
I hope this helps. Best regards, Adam Dybkowski > -----Original Message----- > From: Naveen Kumar [mailto:[email protected]] > Sent: Thursday, 17 October, 2019 17:30 > To: Dybkowski, AdamX <[email protected]>; [email protected] > Cc: Trahe, Fiona <[email protected]> > 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:[email protected]> > Sent: Wednesday, October 16, 2019 2:49 PM > To: mailto:[email protected]; Naveen Kumar > <mailto:[email protected]> > Cc: Trahe, Fiona <mailto:[email protected]> > 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
