DPDK usage discussions
 help / color / Atom feed
* Re: [dpdk-users] AES "Digest-encrypted" crypto chain case.
@ 2019-10-16 12:48 Dybkowski, AdamX
       [not found] ` <9836169a72be40328d96c3c08e78ad3d@de-mta1.commagility.com>
  0 siblings, 1 reply; 7+ messages in thread
From: Dybkowski, AdamX @ 2019-10-16 12:48 UTC (permalink / raw)
  To: users, naveen.kumar; +Cc: Trahe, Fiona

Hi Naveen.

Regarding your message sent to dpdk-users mailing list:

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
  * this field should be in bits.

This also gets built into the documentation available here:

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.


^ permalink raw reply	[flat|nested] 7+ messages in thread
* [dpdk-users] AES "Digest-encrypted" crypto chain case.
@ 2019-09-09  9:15 Naveen Kumar
  2019-09-09 14:08 ` Trahe, Fiona
  0 siblings, 1 reply; 7+ messages in thread
From: Naveen Kumar @ 2019-09-09  9:15 UTC (permalink / raw)
  To: users

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?


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.

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

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-16 12:48 [dpdk-users] AES "Digest-encrypted" crypto chain case Dybkowski, AdamX
     [not found] ` <9836169a72be40328d96c3c08e78ad3d@de-mta1.commagility.com>
2019-10-17 15:30   ` Naveen Kumar
2019-10-18 13:19     ` Dybkowski, AdamX
2019-11-05 11:17       ` Naveen Kumar
  -- strict thread matches above, loose matches on Subject: below --
2019-09-09  9:15 Naveen Kumar
2019-09-09 14:08 ` Trahe, Fiona
2019-09-09 14:27   ` Naveen Kumar

DPDK usage discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/users/0 users/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 users users/ http://inbox.dpdk.org/users \
	public-inbox-index users

Newsgroup available over NNTP:

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