STM32H730 AES-GCM Tag issue

[GCern.1]

STM32H730, an invalid tag is generated for payloads that are not a multiple of 4, as described in Re: STM32U545 AES GCM Tag mismatch - STMicroelectronics Community.

AES-CCM: no issues, everything works.

AES-GCM:

The HAL already handles required padding on its own.

• Encryption and tag generation - work
• Decryption - works
• Tag generation after decryption - invalid
  

Tried with and without AD. Tried to provide AD and/or Ciphertext as a multiple of 4 and 16 bytes (as suggested by other posts; however, the H7 HAL already handles padding). The resulting tag after decoding is invalid for a ciphertext of a length that is not a multiple of 4.

Everything works when the ciphertext is a multiple of 4 bytes (but not when manually padded to such with 0-oes at the end). The ciphertext of 15 bytes won't generate a correct tag, but it works when it is 12 or 16 bytes.

Standard HAL functions are used: HAL_CRYP_Encrypt, HAL_CRYP_Decrypt, HAL_CRYPEx_AESGCM_GenerateAuthTAG, and HAL_CRYP_SetConfig.

What am I doing wrong?

Edit: Will recheck in the CubeMX-generated project.

Example

DataType = CRYP_DATATYPE_8B
DataWidthUnit  = CRYP_DATAWIDTHUNIT_BYTE

All buffers are aligned (i.e. __attribute__((__aligned__(4)))).

Given

Key (128 bits): [0x071b113b, 0x0ca743fe, 0xcccf3d05, 0x1f737382] (end. adjusted)
IV (12 bytes, providing 16): [0xf0761e8d, 0xcd3d0001, 0x76d457ed, 0x00000002] (end. adjusted, counter set to 2)

Encode, generate a tag, decode, generate a tag of 15 bytes:
Plaintext (15 bytes) - [0x08, 0x00, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x15, 0x16, 0x17]

Expected
Ciphertext (15 bytes) - [0x13, 0xB4, 0xC7, 0x2B, 0x38, 0x9D, 0xC5, 0x01, 0x8E, 0x72, 0xA1, 0x71, 0xD1, 0x89, 0xA9]
Tag (16 bytes) - [0x8A, 0x0B, 0xF6, 0xE7, 0xC8, 0xAC, 0x33, 0x47, 0x61, 0x16, 0xED, 0xA8, 0x05, 0x2E, 0xF7, 0xC6]

Results
Encryption and tag generation work, getting:

Ciphertext (15 bytes) - [0x13, 0xB4, 0xC7, 0x2B, 0x38, 0x9D, 0xC5, 0x01 0x8E, 0x72, 0xA1, 0x71, 0xD1, 0x89, 0xA9]
Tag (16 bytes) - [0x8A, 0x0B, 0xF6, 0xE7, 0xC8, 0xAC, 0x33, 0x47, 0x61, 0x16, 0xED, 0xA8, 0x05, 0x2E, 0xF7, 0xC6]

Decryption works, but tag generation fails, getting:
Plaintext (15 bytes) - [0x08, 0x00, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x15, 0x16, 0x17]
Tag (16 bytes) - [0x74, 0x27, 0x4E, 0x06, 0x64, 0x84, 0xD8, 0x4C, 0x04, 0x3E, 0x25, 0x38, 0x15, 0x3A, 0x47, 0xA4] - invalid

Encode, generate a tag, decode, generate a tag of 16 bytes:
Plaintext (16 bytes) - [0x08, 0x00, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x15, 0x16, 0x17, 0xAB]

Expected
Ciphertext (16 bytes) - [0x13, 0xB4, 0xC7, 0x2B, 0x38, 0x9D, 0xC5, 0x01, 0x8E, 0x72, 0xA1, 0x71, 0xD1, 0x89, 0xA9, 0x64]
Tag (16 bytes) - [0x85, 0xE9, 0x98, 0x47, 0xBE, 0x4D, 0xAA, 0xCB, 0x86, 0xFB, 0xCF, 0x00, 0xBE, 0x58, 0x5B, 0x47]

Results
Encryption and tag generation, as well as decryption and tag generation, work as expected.

[Saket_Om]

Hello @GCern.1 

I reported your question internally and will get back to you as soon as possible.

Internal ticket number: 210917 (This is an internal tracking number and is not accessible or usable by customers).

[Saket_Om]

Hello @GCern.1 

Could you share your project please, then we can assist you more effectively. 

[GCern.1]

@Saket_Om I observed that tag generation fails when the ciphertext buffer is allocated on the stack rather than globally. Attached an example.

DMA is not used, D/ICaches are disabled.

In the initial project (not the provided example), the tag is generated correctly when the ciphertext is located at 0x24022ed8, but fails when it is located at 0x24021c98 - both in SRAM, but in that project D/ICache is enabled. But maybe I am digging in the incorrect direction...

What is the reason for such behavior?

[Saket_Om]

Hello @GCern.1 

Please refer to the example below: 

STM32CubeH7/Projects/STM32H735G-DK/Examples/CRYP/CRYP_AES_GCM at master · STMicroelectronics/STM32CubeH7 · GitHub

[GCern.1]

Hello, thank you - I'm aware of the examples, but they don't seem to trigger the issue.

Even in the example I shared earlier (as a zip attachment), it's possible to get it working. However, there is a specific case where it fails. I suspect the problem may be related to memory access and/or cache coherency or something else, though I haven't pinpointed it yet.