Inconsistency between STM32H7 AES HAL and Reference Manual

[Gpeti]

Hello

I'm starting to implement AES-GCM on STM32H753 (rev V).

I've found an inconsistency between the HAL and the Ref Manual.

The STMicro HAL for AES for STM32H7x3 is setting some bits called NPBLB in CRYP_CR register if the product revision is above rev B.

But these bits are not documented in the ref manual rev 7.

Is it just an error of the HAL ?

[CMYL · Accepted solution]

Hello,

The NPBLB feature is supported in STM32H7 revB, RevX and RevV.

When processing the last AES block, the the CPU must pad (when applicable) the data with zeroes to obtain a complete block and specify the number of non-valid bytes using NPBLB bits in CRYP_CR register.

This is documented in RM0468 pp 1457, 1458 and 1498.

The HAL is generic for all revisions, I don't understand why said it is an error in the HAL ?

Best regards

[Piranha]

C'mon, the reference manual for a STM32H753 is RM0433. Therefore this ^ comment is not a correct answer also...

[CMYL]

Hello Piranha,

I totally agree with you :) sorry I missed that you are talking about STM32H753 (rev V, RM0433). To the best of my knowledge, the rev V is updated by GCM padding support + MDMA link.

I will double check if the padding is performed using the bitfield NBLP. if the case then RM0433 needs to be updated. Back to you soon :grinning_face:

Thank you

[Gpeti]

Apparently the bits NPBLB are indeed implemented above rev B. problem is that the ref manual was not updated. It is mentioned in the Migration Guide from rev Y to rev V (sic) but without details of the bits behaviour. You have to get the information in the reference manual of another STM32 implementing the same bits.

[Gpeti]

Younes, it's kinda off topic but I don't understand one point: the ref manual of STM32MP157 where I found details on these bits say that the bits NPBLB must be written before encrypting the last block of data for encryption but not for decryption. This is to avoid that the padded bytes are taken into account in the authentication tag. But then I don't understand why you don't need to do the same (ie. inform the peripheral that the last bytes are only padded bytes) for decryption ?

[Gpeti]

Just found out there might be another error in the documentation. Details here

[CMYL]

Hi Gpeti and Piranha,

1- I confirm, the RM0433 is missing the update of the Padding feature with zeroes to obtain a complete block using NPBLB bit field. The update should distinguish between RevY (wo NPBLB support) and other revisions (w/ NPBLB feature).

2- In my understanding: we specify the number of non-valid bytes using NPBLB bits in CRYP_CR register in case of AES GCM payload encryption or AES CCM payload decryption. Otherwise the tag computation will be wrong. This is detailed in RM0468 for H723/33 H725/35 and H730, it should be the same as H753 rev V with RM0433 updates.

3- (>> Just found out there might be another error in the documentation. Details here) : could we redirect the question to ST community forum ? or create a new request in this forum for tracking the question and correct the documentation ?

Best regards,

Younes