HW crypto slower than SW crypto for certain CCM* vectors

[JCP]

test_crypto.zip

Hi,

I ran some tests with the SW and HW crypto on nrf5340dk. I expected that using the crypto cell would improve my crypto performance tremendously but unfortunately, it did not.

I ran some unit tests and they are better in HW on average but some are worse in HW than they are in SW and those are the ones that I need for my dev.

I'm attaching the sample code I'm using for my tests but here is the essence:

Using the SW encryption, I get a pretty similar performance over the encryption and decryption (west build -p -b nrf5340dk_nrf5340_cpuapp --build-dir build/crypto.sw test_crypto -DOVERLAY_CONFIG=crypto_sw.conf)

Now, using the HW encryption (west build -p -b nrf5340dk_nrf5340_cpuapp --build-dir build/crypto.hw test_crypto -DOVERLAY_CONFIG=crypto_hw.conf), I get very different performance and even worse for some vectors than the SW implementation.

Could you please advise if I did something wrong? Or help me getting this better.

SW crypto output:

*** Booting Zephyr OS build v2.6.99-ncs1-1 ***

Running test suite crypto_tests

===================================================================

START - test_ccm_star_encrypt_vectors

I: test_ccm_star_encrypt_vectors: test 0 duration 16126 cycles

I: test_ccm_star_encrypt_vectors: test 1 duration 15450 cycles

I: test_ccm_star_encrypt_vectors: test 2 duration 15523 cycles

I: test_ccm_star_encrypt_vectors: test 3 duration 15746 cycles

PASS - test_ccm_star_encrypt_vectors in 0.25 seconds

===================================================================

START - test_ccm_star_decrypt_vectors

I: test_ccm_star_decrypt_vectors: test 0 duration 12127 cycles

I: test_ccm_star_decrypt_vectors: test 1 duration 11633 cycles

I: test_ccm_star_decrypt_vectors: test 2 duration 11779 cycles

I: test_ccm_star_decrypt_vectors: test 3 duration 12826 cycles

PASS - test_ccm_star_decrypt_vectors in 0.25 seconds
===================================================================
Test suite crypto_tests succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL

HW crypto output:

*** Booting Zephyr OS build v2.6.99-ncs1-1 ***
Running test suite crypto_tests
===================================================================
START - test_ccm_star_encrypt_vectors
I: test_ccm_star_encrypt_vectors: test 0 duration 17535 cycles
I: test_ccm_star_encrypt_vectors: test 1 duration 175 cycles
I: test_ccm_star_encrypt_vectors: test 2 duration 143 cycles
I: test_ccm_star_encrypt_vectors: test 3 duration 161 cycles
PASS - test_ccm_star_encrypt_vectors in 0.23 seconds
===================================================================
START - test_ccm_star_decrypt_vectors
I: test_ccm_star_decrypt_vectors: test 0 duration 239 cycles
I: test_ccm_star_decrypt_vectors: test 1 duration 17308 cycles
I: test_ccm_star_decrypt_vectors: test 2 duration 197 cycles
I: test_ccm_star_decrypt_vectors: test 3 duration 280 cycles
PASS - test_ccm_star_decrypt_vectors in 0.23 seconds
===================================================================
Test suite crypto_tests succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL

[Einar Thorsrud]

Hi,

There is a complicating factor when using WH acceleration which you don't have with SW, which is that there is a need to lock the HW using a mutex and this leads to some overhead.

There are configurations that allow changing this to a simpler scheme (using atomic locks) but it won't be thread-safe so you have to be very careful about how you call crypto APIs in that case. The biggest problem is the need to get PRNG at random places in the code. This will require use of CTR_DRBG which is the same module as the CCM. There can only be one users of this. If you use atomic locking then you have the possibility of deadlocking yourself if you are requesting PRNG at the same time as doing the CCM operation

Also there is a possibility that the setup of the HW Crypto is also impacting the execution speed, in case the input material is very small.

For larger input data the execution time should consistently be much smaller using HW compared to using SW, and this is normally what is most important.

[JCP]

Would there be a way to use the cc312-runtime lib from ARM so I can tune the locking and accesses? I'm using it with the same crypto cell on another HW and the usage of the HW improved my performance significantly with the same samples.

I tried using it but it looks like the HW is powered down or not clocked and I couldn't get the HW running...

[Einar Thorsrud]

Using the cc312-runtime library directly is not supported. You can experiment with it, but we cannot support it so you will be on your own in that. See this thread.

[JCP]

I've looked at it and even if I understand that you can't support both, I can't have the ARM runtime lib working (the CC seems powered down or unclocked and all the init is in the binary).

I can't use the HW accel either because in my use case, we have short packets by default so I'm at a dead end here...

[Einar Thorsrud]

Hi,

You will get better numbers if you disable the mutex and use atomic locks, but still the worst case numbers with your test code seems to be almost 8000 cycles. It is an improvement though. Use this additional configs for that:

CONFIG_CC3XX_ATOMIC_LOCK=y
CONFIG_CC3XX_HW_MUTEX_LOCK=n

You could also modify or disable the locking altogether by modifying the implementation in nrf_cc3xx_platform_mutex_zephyr.c.