DIfference in results based on different AES mode

[abtom87]

If I use AES mode CRYP_CR_ALGOMODE_AES_CBC, the decryptedText array does not match with the last 3 uint32_t values in the array. Same goes with ECB mode. However, when GCM or CCM modes are used, the decrypted data is same as the plain text. I could not find any hints in the errata sheet either.

Has anyone else faced a similar problem?

#define BUFF_LEN 15

uint32_t AES256Key[8] = {0xB374A26A, 0x71490437, 0xAA024E4F, 0xADD5B497,
                         0xFDFF1A8E, 0xA6FF12F6, 0xFB65AF27, 0x20B59CCF};

uint32_t InitVector[4] = {0x7E892875, 0xA52C59A3, 0xB588306B, 0x13C31FBD};


uint32_t Ciphertext[BUFF_LEN] = {0x42831ec2, 0x21777424, 0x4b7221b7, 0x84d0d49c,
                                 0xe3aa212f, 0x2c02a4e0, 0x35c17e23, 0x29aca12e,
                                 0x21d514b2, 0x5466931c, 0x7d8f6a5a, 0xac84aa05,
                                 0x1ba30b39, 0x6a0aac97, 0x3d58e091};

uint32_t Plaintext[BUFF_LEN] = {0xd9313225, 0xf88406e5, 0xa55909c5, 0xaff5269a,
                                0x86a7a953, 0x1534f7da, 0x2e4c303d, 0x8a318a72,
                                0x1c3c0c95, 0x95680953, 0x2fcf0e24, 0x49a6b525,
                                0xb16aedf5, 0xaa0de657, 0xba637b39};

uint32_t Encryptedtext[BUFF_LEN] = {0};


uint32_t Decryptedtext[BUFF_LEN] = {0};
int main() {

  CRYP_HandleTypeDef hcryp1;
  memset((CRYP_HandleTypeDef *)&hcryp1, 0x00, sizeof(CRYP_HandleTypeDef));

  hcryp1.Instance = CRYP;
  hcryp1.Init.DataType = CRYP_DATATYPE_32B;
  hcryp1.Init.KeySize = CRYP_KEYSIZE_256B;
  hcryp1.Init.pKey = AES256Key;
  hcryp1.Init.Algorithm = CRYP_CR_ALGOMODE_AES_CBC;
  hcryp1.Init.pInitVect = InitVector;
  HAL_CRYP_Init(&hcryp1);
  HAL_CRYP_Encrypt(&hcryp1, Plaintext, BUFF_LEN, Encryptedtext, TIMEOUT_VALUE);

  HAL_CRYP_Decrypt(&hcryp1, Encryptedtext, BUFF_LEN, Decryptedtext,
                   TIMEOUT_VALUE);
  HAL_CRYP_DeInit(&hcryp1);

  if (memcmp(Decryptedtext, Plaintext, 60) != 0) {
    /* Not expected result, wrong on Encryptedtext buffer: Turn LED3 on */
    // Error_Handler();
  }
}

[Bubbles]

Hi @abtom87,

this is normal and intended behavior. Different chaining methods simply do produce different results.

BR,

J

[Tesla DeLorean]

Probably need  DeInit/Init between sequences, not linear drop-thru behaviour, and make sure the Init parameters aren't changed so startup conditions are consistent. 

[abtom87]

You mean deinit after encrypt and then init before decrypt and then deinit? startup parameters are set constant. What do you mean exactly?

[Tesla DeLorean]

I mean that for the startup conditions for the Encrypt and Decrypt cycles need to be the same, same keying, block/cycling. You can't just restart the operations in some middle / intermediate state, and expect to change direction. They are symmetrical, but need to start from initial conditions.

Try

int main()
{
  CRYP_HandleTypeDef hcryp1 = {0}; // clears the local/auto variable
 
  hcryp1.Instance = CRYP;

  hcryp1.Init.DataType = CRYP_DATATYPE_32B;
  hcryp1.Init.KeySize = CRYP_KEYSIZE_256B;
  hcryp1.Init.pKey = AES256Key;
  hcryp1.Init.Algorithm = CRYP_CR_ALGOMODE_AES_CBC;
  hcryp1.Init.pInitVect = InitVector;
 
  HAL_CRYP_Init(&hcryp1);
  HAL_CRYP_Encrypt(&hcryp1, Plaintext, BUFF_LEN, Encryptedtext, TIMEOUT_VALUE);
  HAL_CRYP_DeInit(&hcryp1);

  HAL_CRYP_Init(&hcryp1);
  HAL_CRYP_Decrypt(&hcryp1, Encryptedtext, BUFF_LEN, Decryptedtext,
                   TIMEOUT_VALUE); // 32-bit word ptr, and word count, not byte count
  HAL_CRYP_DeInit(&hcryp1);

  if (memcmp(Decryptedtext, Plaintext, BUFFLEN * sizeof(uint32_t)) != 0) {
    /* Not expected result, wrong on Encryptedtext buffer: Turn LED3 on */
    // Error_Handler();
  }
}

[abtom87]

No, it did not work unfortunately, last 3 uint32_t values still differ.

[Tesla DeLorean]

Which STM32 MCU are you using?

[abtom87]

STM32H753

[AA1 · Accepted solution]

"the decryptedText array does not match with the last 3 uint32_t values in the array."

For AES CBC and ECB, text length must be multiple of AES block size (16 bytes).

In your case text length is 60 bytes and it is truncated to 48 bytes (16x3). 60 - 48 = 12 bytes or 3 uint32_t values. When text length is not multiple of AES block size, need to add padding. In your case you need to add 4 bytes of padding, so text length is 64 bytes.

[Tesla DeLorean]

Good catch, AES mixes across the whole block

With CTR you'd get the whole block, and then have to apply only within the limits of the data