PSA encryption - AES CTR 128 - message input length

[Regie Roshan Magendiran]

Hello,

I am porting to nRF5340 from nRF52833. Previously, we were using sdk17.0.2 for nRF52833 and we were able to successfully implement encryption algorithm AES-CTR-128 with sdk 17.0.2.

Now that we are porting to nRF5340, we would want to implement the same encryption algorithm using Zephyr and NCS sdk.

I'm using the NCS 1.9.1 sdk and I was able to implement the PSA encryption AES-CTR-128 algorithm based on the example found in v1.9.1\nrf\samples\crypto\aes_ctr\

I was able to encrypt input messages successfully. But these input messages had to be multiples of 16 bytes. If I send a message of the size that is not a multiple of 16 bytes, 

psa_cipher_update() returns PSA_ERROR_INVALID_ARGUMENT. This was not the case with sdk17.0.2 with nRF52833. I was able to encrypt messages of any length. 

I also understand that AES-CTR-128 algorithm does need padding. So it should be possible to encrypt/decrypt message of any length.

Could you let me know what I could be doing wrong? And how to achieve encryption using AES-CTR-128 algorithm for input messages of any length.

Thanks for your time!

Regards,
Regie

[Sigurd Hellesvik]

encrypt

Hi Regie,

I do not think I understand your question.
When I try to replicate your issue, I change the following:

diff --git a/samples/crypto/aes_ctr/src/main.c b/samples/crypto/aes_ctr/src/main.c
index a76cd2f44..896868255 100644
--- a/samples/crypto/aes_ctr/src/main.c
+++ b/samples/crypto/aes_ctr/src/main.c
@@ -40,7 +40,7 @@ static uint8_t m_iv[NRF_CRYPTO_EXAMPLE_AES_BLOCK_SIZE];
 
 /* Below text is used as plaintext for encryption/decryption */
 static uint8_t m_plain_text[NRF_CRYPTO_EXAMPLE_AES_MAX_TEXT_SIZE] = {
-       "Example string to demonstrate basic usage of AES CTR mode."
+       "Example string "
 };
 
 static uint8_t m_encrypted_text[NRF_CRYPTO_EXAMPLE_AES_MAX_TEXT_SIZE];

But it runs fine, with the log as follows:

*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.415,924] <inf> aes_ctr: Starting AES CTR example...
[00:00:00.415,924] <inf> aes_ctr: Generating random AES key...
[00:00:00.416,168] <inf> aes_ctr: AES key generated successfully!
[00:00:00.416,168] <inf> aes_ctr: Encrypting using AES CTR MODE...
[00:00:00.416,625] <inf> aes_ctr: Encryption successful!

[00:00:00.416,625] <inf> aes_ctr: ---- IV (len: 16): ----
[00:00:00.416,656] <inf> aes_ctr: Content:
                                  39 0c fe 12 ff 66 6c 31  95 01 8d a5 35 e0 96 54 |9....fl1 ....5..T
[00:00:00.416,656] <inf> aes_ctr: ---- IV end  ----
[00:00:00.416,656] <inf> aes_ctr: ---- Plaintext (len: 128): ----
[00:00:00.416,717] <inf> aes_ctr: Content:
                                  45 78 61 6d 70 6c 65 20  73 74 72 69 6e 67 20 00 |Example  string .
                                  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 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  00 00 00 00 00 00 00 00 |........ ........
[00:00:00.416,717] <inf> aes_ctr: ---- Plaintext end  ----
[00:00:00.416,717] <inf> aes_ctr: ---- Encrypted text (len: 128): ----
[00:00:00.416,748] <inf> aes_ctr: Content:
                                  59 52 a9 d6 e4 da b1 69  7f 74 94 f8 8f 22 ca 0b |YR.....i .t..."..
                                  36 e2 9c 9d ed f7 c9 15  e1 df 75 de 6e 42 bf 49 |6....... ..u.nB.I
                                  3e 29 3a 45 83 16 4b 50  b9 e2 47 96 69 60 3f b5 |>):E..KP ..G.i`?.
                                  b0 19 a4 27 03 55 3b d8  b0 0e 7a 07 bf 9a 81 dd |...'.U;. ..z.....
                                  be 6f c2 13 8a ce e4 26  17 e4 f5 66 ea 75 9f ed |.o.....& ...f.u..
                                  89 58 04 37 e1 ad 52 14  d7 a9 da dd 2d a9 51 f7 |.X.7..R. ....-.Q.
                                  de 9e b5 e4 c3 7d b1 e8  d7 93 f1 eb fc 1c 93 b7 |.....}.. ........
                                  d8 b7 86 c4 ff 7e f8 84  77 99 05 98 a2 ca 89 20 |.....~.. w...... 
[00:00:00.416,778] <inf> aes_ctr: ---- Encrypted text end  ----
[00:00:00.416,778] <inf> aes_ctr: Decrypting using AES CTR MODE...
[00:00:00.417,114] <inf> aes_ctr: ---- Decrypted text (len: 128): ----
[00:00:00.417,144] <inf> aes_ctr: Content:
                                  45 78 61 6d 70 6c 65 20  73 74 72 69 6e 67 20 00 |Example  string .
                                  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 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  00 00 00 00 00 00 00 00 |........ ........
[00:00:00.417,144] <inf> aes_ctr: ---- Decrypted text end  ----
[00:00:00.417,236] <inf> aes_ctr: Decryption successful!
[00:00:00.417,297] <inf> aes_ctr: Example finished successfully!

Are you looking for something other than this?

Regards,
Sigurd Hellesvik

[Regie Roshan Magendiran]

Hi Sigurd,

Thanks for trying it out. Let me give you more information about what I'm trying to implement.

In your example you are maintaining a buffer of 128 bytes (initialized to zero), and I think, your input message length is 15 bytes here. This gets encrypted using the algorithm which outputs a 128 bytes encrypted cipher text. So for an input message length of 15 bytes, the encrypted output length is 128 bytes.

In our application, we need the same encrypted output length as the input length, for example,  for 15 bytes input length, we would need 15 bytes encrypted output. We had this implemented using the sdk17.0.2. Our application involves in sending the encrypted text via BLE and we cannot afford to send more (extra) bytes due to our high transmission frequency. 

To implement this with the PSA crypto example in ncs sdk, I simply changed the size of the input message and the output length buffer in psa_cipher_update(), but as I said earlier, I received  PSA_ERROR_INVALID_ARGUMENT. Then as I debugged more, I found out that the input message length should be in multiples of 16 bytes. But if I understand correctly, for AES-CTR-128, this should not be the case. AES-CTR-128 should be able to output an encrypted output of the same length as its input message length. I also remember, this was one of the reason why we chose AES-CTR-128 (padding is not required).

So I would need AES-CTR-128 encryption that would give the same encrypted output length as the input message length. 

Why isn't this possible? Or am I doing something wrong?

Thanks for your time again!

Regie

[Sigurd Hellesvik]

Hi Regie,

Thanks for explaining your issue, I get it now.

I will ask our crypto experts if there any rules for about the output length.

In the meantime, maybe PSA_CIPHER_UPDATE_OUTPUT_SIZE would be helpful to get output sizes.

Regards,
Sigurd Hellesvik

[Regie Roshan Magendiran]

I did try  PSA_CIPHER_UPDATE_OUTPUT_SIZE earlier. I tried it again to re-confirm. So for an input message length of 76 bytes, key type PSA_KEY_TYPE_AES, and algorithm PSA_ALG_CTR, the output buffer size is 76 bytes. But when I feed a input and output buffer length of 76 bytes to psa_cipher_update(), it returns PSA_ERROR_INVALID_ARGUMENT.

Regards,
Regie

[Sigurd Hellesvik]

Our developers say:

"There is a limitation in the ncs v1.9.1 which only allows multiple of block size input and outputs. The 1.9 was the first release which supported the PSA APIs. This issue is fixed in the ncs v.2.0.x which I highly suggest to use for this. For the v.1.9.1 a workaround is to use the PSA Oberon driver. "

Does this work for you?

Regards,
Sigurd Hellesvik

[Regie Roshan Magendiran]

Thanks for the response, Sigurd!

Would PSA Oberon library use the CryptoCell 312 in nRF5340? I would like to use the library that uses the hardware for faster computation or remove as much load as possible from the CPU.

Regards,
Regie

[Sigurd Hellesvik]

Hi

No, Oberon is a software crypto driver, and will not use the CryptoCell.

Regards,
Sigurd Hellesvik

[Regie Roshan Magendiran]

I see. Then it makes sense to update to the new NCS version. Thanks again for sorting it out!