Wrong maci with snow3g UIA2 in LSDK20.04

[Mercurial]

Hi NXP:

I want to do Integrity Protection with SNOW3G on DPDK 

but the program computes a wrong maci while doing DL packeting with iperf 400M

The QXDM shows that the algorithm computed a wrong maci:

I tried another snow3g code and get the same result with QXDM log.

my config is 

Integrity key:

522D7889B88313A4581B582FE3CCBD36

count :64456

rb_id:0

direction:1(DL)

data:

{0x80,0xFB,0xC8,0x01,0x45,0x00,0x00,0x7A,0x7D,0xDE,0x00,0xAC,0x40,0x11,0xD4,0x83,0x0E,0x2D,0x00,0x01,0x0E,0x2D,0x0B,0x0B,0x38,0x39,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39}

length:1008(128 bytes x8)

I wonder if something goes wrong in computing maci.

Thank you.

[yipingwang]

Please refer to

https://community.nxp.com/t5/Layerscape/LX1046A-SEC-SNOW3G-and-ZUC-crypto-support-in-LSDK20-04/td-p/...

[Mercurial]

I have viewed that article before.But i can't get libsso_snow3g as the document of dpdk 19.11 shows:

17. SNOW 3G Crypto Poll Mode Driver — Data Plane Development Kit 19.11.14 documentation (dpdk.org)

The resouce seems removed.

So i compiled dpdk 22.10 on my visual machine instead. I got the right maci with replaced test data and original test program.The IV is computed by another snow3g program.I still wonder if something went wrong with the version in use.

I have checked our program and input data many times.The program always compute a wrong maci when count comes to a random number between 59000 & 65000.

[hemantagrawal]

The git has been moved to: (nxpmicro to nxp) https://github.com/NXP/dpdk/tree/19.11-qoriq

use the latest commit from here. There are many fixes in PDCP implementation and standalone snow3G based HW processing is also supported in some cases.

libsso_snow3g is not for ARM based platforms

if you want to checkout software based ARM crypto libraries. you can either use openssl or checkout

Algorithm	PMD	Link
AES(128)-CBC+HMAC-SHA1@1024 bytes	Armv8 master branch	https://github.com/ARM-software/AArch64cryptolib
AES-CTR@1024 bytes	OpenSSL 3.1.1	https://github.com/openssl/openssl/releases/tag/openssl-3.1.1
SNOW3G-UEA2@1024 bytes	ipsec-mb  tag: SECLIB-IPSEC-2023.06.20	https://gitlab.arm.com/arm-reference-solutions/ipsec-mb/-/tags
SNOW3G-UIA2@1024 bytes	Ipsec-mb  tag: SECLIB-IPSEC-2023.06.20	https://gitlab.arm.com/arm-reference-solutions/ipsec-mb/-/tags

NXP has not tested them, but they shall work on A72/A53 cores.

[Mercurial]

sry, i have figured out how to run dpdk-test on our device in stead of the virual machine. I modified the test data and ran the cryptodev_dpaa_sec_autotest.I got the right maci with the unit test.I compared our code with the test program and fount nothing different except the order of the code.After eliminating the differences,the results made no difference.

However,when i turned hfn_ovrd from 1 to 0.everything went well until hfn turned over.So i mannually modified the hfn value and create a new crypto session to replace the old one.It seems ok in this situation.UE didn't detach in early time.

I tried to use the data in dpdk-test which hfn values 1.but it computed a wrong value of maci.While the wrong value is as same as one the snow f9 program I found on the internet.

test data parameters in attachment