STM32U585: AES GCM Tag mismatch

[SafeDev]

Good afternoon,

we are facing issue with AES GCM Tag generated with STM32U585.

In particular we compare the results generated by the microcontroller with the ones generated by an application developed with C#.

This is the code running on the microcontroller

Key size is 256 Bit set to all 0 just to speed operations. Tag size is 128 bit. I know that the IV vector must have the last byte set as 2 an I dit it as requested.

uint32_t pKeyAES[8] = {0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000};

uint32_t pInitVectAES[4] = {0x00000000,0x00000000,0x00000000,0x00000002};

__ALIGN_BEGIN static const uint32_t HeaderAES[4] __ALIGN_END = {

0x24825602,0xbd12a984,0xe0092d3e,0x448eda5f};

Plaintext is a simple 48 bytes buffer (so a multiple of 16).

The EncryptedText is identical to the one generated by the application: good.

On the other hand the generated Tag is always different....maybe we are doing something wrong....could you help us with this topic?

Thanks

Best regards

[Tesla DeLorean]

This strikes me as being internally inconsistent.

hcryp.Init.Header = (uint32_t *)HeaderAES;
hcryp.Init.HeaderSize = 12; // 12 32-bit words, 48 bytes
hcryp.Init.HeaderWidthUnit = CRYP_HEADERWIDTHUNIT_BYTE;

Generally these things often boil down to endianess / byte order, especially when not applied uniformly / consistently, or just differently.

Step#1 would be to get the NIST examples to work on ALL platforms

If you want others to participate, don't post bitmaps of code fragments, post stuff that's sufficiently complete and buildable that it's not a heavy lift to see what you see. Ideally making the example(s) self-testing such that parameters and byte ordering can be tuned and success/failure against your criterion quickly tested and affirmed.

From ST, I'd like to see more resilient examples, showing common use cases or protocols using the methods, with the byte ordering they use.