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.

[SafeDev]

Hi Tesla,

I agree, I will try some combination about byte swap, size etc.

Netx time I will post the entire code.

Thank you for the hints.

Best regards

[CMYL]

Hello @SafeDev and @Tesla DeLorean 

Attached the main.c file that implements correctly the vector test from NIST that I shared above.

We need to work with byte width as plaintext is not a multiple of words (32-bit). Otherwise extra 0 bits (8 '0' here) are computed for tag and Cipher text. The changes that I made are followed by comments in the code snippet below

#define PLAINTEXT_SIZE   51 /*13 *//* Plaintext size in Words --> bytes*/
#define KEY_SIZE          8 /*4*/ /* Key size in word --> bytes*/

static void MX_AES_Init(void)
{
  hcryp.Instance = AES;
  hcryp.Init.DataType = CRYP_NO_SWAP;  
  hcryp.Init.KeySize = CRYP_KEYSIZE_256B; //CRYP_KEYSIZE_128B;
  hcryp.Init.pKey = (uint32_t *)pKeyAES;
  hcryp.Init.pInitVect = (uint32_t *)pInitVectAES;
  hcryp.Init.Algorithm = CRYP_AES_GCM_GMAC;
  hcryp.Init.Header = (uint32_t *)HeaderAES;
  hcryp.Init.HeaderSize = 48; //12
  hcryp.Init.DataWidthUnit = CRYP_DATAWIDTHUNIT_BYTE; // word
  hcryp.Init.HeaderWidthUnit = CRYP_HEADERWIDTHUNIT_BYTE; // word
  hcryp.Init.KeyIVConfigSkip = CRYP_KEYIVCONFIG_ALWAYS;
  hcryp.Init.KeyMode = CRYP_KEYMODE_NORMAL;
  if (HAL_CRYP_Init(&hcryp) != HAL_OK)
  {
    Error_Handler();
  }
}

 Best Regards,

Younes

[SafeDev]

Hi  Younes,

I have run your code (see attachment) and still have tag mismatch.

What could be the problem?

Thanks.

Best regards

[CMYL · Accepted solution]

Hi @SafeDev 

So sorry again, seems I missed some modifications in the last main.c file. Attached the correct one.

This time I did the full test as you see the snapshot below. We need 0-padding  of both PlainText and CipherText arrays during both encryption and decryption. Otherwise, the last word of the PT and CT streams will be different from the provided NIST vectors. The added "0" will be ignored by passing the correct size in bytes of PT and CT.

Below the modified PT/CT streams with padding and Attached the new main.c file.

I will ask internally to either update the CRYP drivers API or give clear guidelines to show how to handle inputs that are not multiple of  32-bits.

uint32_t Plaintext[] = { /*51 bytes */
 0xe7d1dcf6, 
 0x68e28768,
 0x61940e01,
 0x2fe52a98,
 0xdacbd78a,
 0xb63c0884,
 0x2cc9801e,
 0xa581682a,
 0xd54af0c3,
 0x4d0d7f6f,
 0x59e8ee0b,
 0xf4900e0f,
 0xd8504200 /* padding here is mandatory */
};

uint32_t Ciphertext[] =  { /* 51 bytes */
  0x8886e196,
  0x010cb384,
  0x9d9c1a18,
  0x2abe1eea,
  0xb0a5f3ca,
  0x423c3669,
  0xa4a8703c,
  0x0f146e8e,
  0x956fb122,
  0xe0d721b8,
  0x69d2b6fc,
  0xd4216d7d,
  0x4d375800 /* padding here is mandatory */

 Best regards

[SafeDev]

Hi Younes,

thank you, now it works.

Best regards