cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H753ZI CRYP module, AES-CTR, counter register, documentation vs observations

AFerr.17
Associate

Hello,

So I'm using a Nucleo-H753ZI (so STM32H753ZI) and I am trying to implement manually (aka without using the HAL library you provide) some drivers of the CRYP module. More precisely, I need to use the CRYP module with AES in counter mode (AES-CTR, 128 bit keys).

My issue is that I think the documentation on this part contains a slight discrepancy. I am referring to the document "RM0433 Rev 7". On page 1306, (in the CRYP AES-CTR chapter) we find:

0693W00000BcKeGQAV.pngTo me, it looks clear the AES counter is stored in register CRYP_IV0L. Furthermore, the document states that "the peripheral increments the least significant 32 bits (leaving the other most significant 96 bits unchanged).". To me, that confirms that CRYP_IV0L contains the counter and will be incremented for each block. However, I found no success in implementing the driver by configuring the counter with CRYP_IV0L, but the encryption and decryption do work flawlessly when the counter is stored in CRYP_IV1R.

My point is that I think this table (along with some text around it) is incorrect as the counter in AES-CTR mode is stored in CRYP_IV1R, and not in CRYP_IV0L.

A simple test can be done to verify my claim. Using a reference AES-CTR implementation to reduce the possible errors (non-ST, any online tool will do), we can check the following: we use a key full of zeros (aka 0x0 on 16 bytes) and an IV also full of zeros (on 16 bytes) to encrypt a message made of 32 bytes of zeros. The first block is encoded as "0x66 E9 4B D4 EF 8A 2C 3B 88 4C FA 59 CA 34 2B 2E" and the second as. "0x 58 E2 FC CE FA 7E 30 61 36 7F 1D 57 A4 E7 45 5A".

Plugging the numbers in the STM32H753, we get the correct result as expected.

Right after that, reading the values of CRYP_IV0[/1]R[/L] we expect every register to stay at 0, expect the counter (IV0L according to the documentation) which should be incremented. The problem is that CRYP_IV0L is still at 0, while CRYP_IV1R now reads "0x2". Further verifying, using the same key, setting CRYP_IV0[/1]R[/L] to 0 expect for CRYP_IV1R which we set to 1, the board returns "0x 58 E2 FC CE FA 7E 30 61 36 7F 1D 57 A4 E7 45 5A", which is the second block of the initial "null" message, so indeed the counter is stored in CRYP_IV1R and not in CRYP_IV0L, unlike the previous table states. Also trying to set a counter of "1" in CRYP_IV0L with the same keys and messages results in "0x EE 94 4B 2F E6 E9 FC 88 80 42 60 8D A9 61 5F 75", which is not correct.

For reference, content of the registers after a single block encryption and initial IV of 0:

0693W00000BcKxIQAV.pngAnd configuration of the CRYP module:

0693W00000BcLFRQA3.pngIs there something I am missing or is there really an error in the documentation?

Thank you for your time,

Best,

Alex.

3 REPLIES 3
Jocelyn RICARD
ST Employee

Hello Alex,

thank you for raising this issue in documentation and providing very detailed explanation.

I will request for an update internally

Best regards

Jocelyn

MSaez.1
Associate II

Hello,

any update regarding this issue? I am having quite a lot of problems implementing CTR Encryption/Decryption. Is the documentation or the drivers wrong? I have seen other posts claiming similar problems?

Thank you and best regards

Jocelyn RICARD
ST Employee

Hello @MSaez.1​ ,

I'm sorry I don't catch your point. I understood the documentation was wrong, where IV register names were in reverse order. Is there something else ?

Best regards

Jocelyn