Cypher using AES 128 CTR

[Dosan]

Hi,

Im trying to encryp using AES 128 CTR but i dont get the same result that online calculators.

Im using this online calculator: https://cryptii.com/pipes/aes-encryption

My code is the next:

uint8_t IVKey[] = {0xDD, 0xF9, 0x11, 0xA6, 0xDD, 0xF9, 0x11, 0xA6, 0xDD, 0xF9, 0x11, 0xA6, 0xDD, 0xF9, 0x11, 0xA6};

	AesDeInit();

	// CTR AES
  hcryp.Instance = AES;
  hcryp.Init.DataType = CRYP_DATATYPE_1B;
  hcryp.Init.KeySize = CRYP_KEYSIZE_128B;
  hcryp.Init.pKey = (uint32_t *)AESKey;
  hcryp.Init.Algorithm = CRYP_AES_CTR;
  hcryp.Init.pInitVect = (uint32_t *)IVKey;

  if (HAL_CRYP_Init(&hcryp) != HAL_OK)
  {
    Error_Handler();
  }

and the AESKey is the next:

const uint8_t AESKey[] =
{0x44, 0x26, 0x44, 0x20, 0x45, 0x6C, 0x65, 0x74, 0x74, 0x72, 0x6F, 0x6E, 0x69, 0x63, 0x61, 0x20
};

My AES function is the next:

int16_t AesEncrypt(char *In,int16_t Len)
{
	uint8_t Buf[16];

	if (Len & 0x0F)					
		Len+=16-(Len & 0x0F);

	if (HAL_CRYP_DeInit(&hcryp)!=HAL_OK)
		Len=0;
	else if (HAL_CRYP_Init(&hcryp)!=HAL_OK)
		Len=0;
	else
	{
		for (int16_t i=Len;i>0;i-=16)				// Encripta paquete
		{
			if (HAL_CRYP_Encrypt(&hcryp,(uint32_t *)In,16,(uint32_t *)Buf,255)!=HAL_OK)
			{
				Len=0;
				break;
			}
			memcpy(In,Buf,16);
			In+=16;
		}
	}

	return Len;
}

and the string insert into the function is

char Message2[] = {0x50, 0x00, 0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x01, 0x03, 0x08, 0x20, 0x00, 0x00, 0x00, 0x00};

The result with the online calculator is: 6c 9d 95 e6 9a 75 ed 03 7c a2 81 80 f9 a6 c3 18

The result that im getting is: c4, b0, c3, 8d, 2d, b2, 5b, 20, 89,75, 57 76, 83, 06, be, 1e

My result is wrong t i dont know what am i doing wrong.

Any suggestion?

Thanks,

Best Regards,

[Tesla DeLorean]

The wording here is super-awkward, the terms seem mixed around

What I can tell you from direct observation is that there's over-spill in the byte output buffer, as the library writes words, when given a byte length. I'm not sure the Zero padding is required, the task doesn't need it, but it will write out content to the destination buffer as if it's expecting word alignment. Writing zeros to an in-situ buffer, beyond it's size, isn't more desirable than any other data.

And to my earlier point the ICB and Data sections of "16-byte boundaries" are not treated consistently wrt "swap management", I'm not sure these are exactly complaints, as much as expressions of pitfalls the average user here might fall into, and perhaps need more prose and illustration.

[Jocelyn RICARD]

Hello @Tesla DeLorean ,

I agree reference manual could be more precise, now the actual behavior completely depends on the driver.

The HAL works on a 32 bits basis so if data is not aligned with 32 bits you need to provide a buffer 32bits aligned. The HAL is made to address main features. Unfortunately, it does not address all possible configurations.

Also, I agree this plaintext padding mentioned in RM is not necessary as you will not use the concerned bytes. This can comes from other AES modes where 0 padding is used or good practice. I don't know.

Best regards

Jocelyn