DPDK usage discussions
 help / color / mirror / Atom feed
* pkt encrypt/decrypt issue with DPDK crypto 22.11.2
@ 2023-02-21  8:48 Subrata Nath
  0 siblings, 0 replies; only message in thread
From: Subrata Nath @ 2023-02-21  8:48 UTC (permalink / raw)
  To: users


[-- Attachment #1.1: Type: text/plain, Size: 3162 bytes --]

Hi All,

I am using DPDK version 22.11.2 with intel multi buffer library [
https://github.com/intel/intel-ipsec-mb] version 1.3. I have
followed examples/l2fwd-crypto and other DPDK examples provided with crypto
lib.  I am checking the decryption part on the receiver side with this
version whereas the packet is encrypted with an older version of dpdk
crypto and transmitted. Wireshark is able to decrypt the ciphered packet
properly with the Auth/Cipher keys provided. Wireshark screenshot is
attached. Auth Algo used is HMAC-SHA-1-96, Cipher Algo - AES-CBC with IPSec
tunnel mode.

I am facing an issue where first 16 bytes of the decrypted packet from DPDK
cryptodev deque,  is not correct and rest of the bytes in the decrypted
payload including padding and digest, is fine and matching with wireshark
decrypted one.  Have Anyone faced similar issue?

Note: Xform cipher.iv.offset = IV_OFFSET and length is set to 16. For Auth,
it's 0 and for decryption auth and cipher xforms are chained.

Here is the hexdump of rte_mbufs along with the different fields :

*1.Received encrypted packet:*

45 00 00 d0 00 00 00 00 3e 11 61 fb 0a 15 03 fe
0a 12  01 fe                    ==> Outer IP in plain
11 94 11 94 00 bc 00 00  ===> Outer UDP header in plain
23 6c 43 17                   =====> *ESP SPI*
00 00 00 48                   =====>* ESP sequence number*
49 27 43 21 2a d2 18 52 c1 cc 00 39 ae ba 24 5a   ====> *16 byte IV *
e3 06 ab f6 10 6c 32 f8 7a b3 72 17 76 8c 56 c2  ===> encrypted payload
54 e6 f7 79 5b c8 f4 23 65 7f b5 79 bd a2 83 f8
57 a4 13 57 4a e7 21 7a 34 81 96 96 0e b2 10 7e
e3 59 67 26 a4 d6 2a c7 65 0e 56 49 20 9d
5b 5b 17 c9 52 3a ac 81 c8 ef cd 13 3f 52 b2 a6
3d b4 88 16 2d d0 3c 8c c3 fe 63 e9 9b 88 59 d4
4a 3d d6 0c 1b 6c 02 d0 9f ff e6 16 d4 c3 21 bd
10 35 0d d3 3b b3 b2 70 35 3d f0 46 97 97 60 9f
67 f8 d3 3b d6 a6 c7 92 28 83 24 b8 e8 53 8d 4b
70 4e fa d9 fd 74 47 50 16 31 f1 ea 3b c0

*2. Decrypted Packet from DPDK cryptodev after dequeue*

45 00 00 d0 00 00 00 00 3e 11 61 fb 0a 15 03 fe
0a 12 01 fe                                 -------> Outer IP Header
11 94 11 94 00 bc 00 00             =====> outer UDP Header

23 6c 43 17                               ---------> ESP SPI
00 00 00 48                                 =====>* ESP sequence number*
49 27 43 21 2a d2 18 52 c1 cc 00 39 ae ba 24 5a  ====> *16 byte IV*

*0d 26 43 a7 2a d2 18 52 3e 42 a1 ed e2 d9 24 9b  * ====> *decrypted
payload*
9d 66 97 56 12 b5 16 8a 00 72 00 00 08 00 00 00
46 7f b8 00 68 54 ed 00 0d 54 00 00 00 00 02 02
08 00 45 00 00 54 87 a4 40 00 3f 01 a9 ca 02 01
03 7d 02 01 02 bc 08 00 02 ff 28 05 00 00 dd 2c
ef ce 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00

01 02 03 04 05 06 07 08 08 04   ======> 8 byte padding
fa d9 fd 74 47 50 16 31 f1 ea 3b c0      ==> 12 byte Digest

Here in the decrypted pkt, first 16 byte is not correct and rest of the
part of payload, padding , digest all are matching with the wireshark
decrypted one. Please let me know if I am missing any thing. it will be
great help. Thanks.

Regards,
Subrata

[-- Attachment #1.2: Type: text/html, Size: 3950 bytes --]

[-- Attachment #2: wireshark_decrypt.png --]
[-- Type: image/png, Size: 76975 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-02-21  8:48 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-21  8:48 pkt encrypt/decrypt issue with DPDK crypto 22.11.2 Subrata Nath

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).