STM32 Cryptographic library. AES 128bits example fails??

[spankingnator]

Posted on May 27, 2016 at 13:26

Hi,

I�m trying to use the �STM32 Cryptographic library package V2.0.6� provided from ST on my STM32F030 device.

I�m using IAR Workbench 7.30 and example (AES CTR) compiles without any error.

The problem is that data encrypted doesn�t match with expected data. 

The Key data, IV, plaintext and expected data is being used as example default. I have not touched anything:

const uint8_t Plaintext[64] =

  {

    0x6b, 0xc1, 0xbe, 0xe2, 0x2e, 0x40, 0x9f, 0x96,

    0xe9, 0x3d, 0x7e, 0x11, 0x73, 0x93, 0x17, 0x2a,

    0xae, 0x2d, 0x8a, 0x57, 0x1e, 0x03, 0xac, 0x9c,

    0x9e, 0xb7, 0x6f, 0xac, 0x45, 0xaf, 0x8e, 0x51,

    0x30, 0xc8, 0x1c, 0x46, 0xa3, 0x5c, 0xe4, 0x11,

    0xe5, 0xfb, 0xc1, 0x19, 0x1a, 0x0a, 0x52, 0xef,

    0xf6, 0x9f, 0x24, 0x45, 0xdf, 0x4f, 0x9b, 0x17,

    0xad, 0x2b, 0x41, 0x7b, 0xe6, 0x6c, 0x37, 0x10

  };

uint8_t Key[16Y] =

  {

    0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6,

    0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c

  };

uint8_t IV[16] =

  {

    0xf0 , 0xf1 , 0xf2 , 0xf3 , 0xf4 , 0xf5 , 0xf6 , 0xf7,

    0xf8 , 0xf9 , 0xfa , 0xfb , 0xfc , 0xfd , 0xfe , 0xff

  };

const uint8_t Expected_Ciphertext[64] =

  {

    0x87, 0x4d, 0x61, 0x91, 0xb6, 0x20, 0xe3, 0x26,

    0x1b, 0xef, 0x68, 0x64, 0x99, 0x0d, 0xb6, 0xce,

    0x98, 0x06, 0xf6, 0x6b, 0x79, 0x70, 0xfd, 0xff,

    0x86, 0x17, 0x18, 0x7b, 0xb9, 0xff, 0xfd, 0xff,

    0x5a, 0xe4, 0xdf, 0x3e, 0xdb, 0xd5, 0xd3, 0x5e,

    0x5b, 0x4f, 0x09, 0x02, 0x0d, 0xb0, 0x3e, 0xab,

    0x1e, 0x03, 0x1d, 0xda, 0x2f, 0xbe, 0x03, 0xd1,

    0x79, 0x21, 0x70, 0xa0, 0xf3, 0x00, 0x9c, 0xee

  };

Once the function �STM32_AES_CTR�_Encrypt is called, I don't get the expected_ciphertext.  I got these data instead:

0x70, 0x2b, 0x25, 0x75, 0x00, 0x00, 0x00 � 

I�m trying to debug on hardware based on STM32F030C8, and also SIMULING by Software . The result is the same.

Does anybody knows why?

Any help would be much appreciated.

Thank you in advance,

Regards.

#crypto-aes-encrypt-stm32

[Amel NASRI]

Posted on May 27, 2016 at 16:59

Hi nator.spanking,

The same example is working as expected with my Nucleo F030.I got a similar result as yours when ''

Crypto_DeInit'' is commented.

Please check that this function is called in your project.-Mayla-

[spankingnator]

Posted on May 30, 2016 at 13:08

Thanks for your answer Mayla.

Yes, “Crypto_DeInit()â€� function is called before to STM32_AES_CTR_Encrypt()As I told, I have not modified anything of the example.The example that I’m testing is located in the next path of the Crypto Package provided by ST:…\STM32 Cryptographic library package V2.0.6\Project\STM32F0xx_Cryptographic_Templates\EWARMI also tried to modify optimizations on IAR Workbench (7.30), but I got the same bad result.Also tried to change CTR by CBC encryption method and the result again is wrong.Any help or idea is welcome.  I’m in a hurry.ThanksRegards

[spankingnator]

Posted on May 31, 2016 at 14:45

Hi,

Already tested with CTR and CBC encryption methods. None of them return expected data.:(Thank you.Regards.

[Tesla DeLorean]

Posted on June 01, 2016 at 02:14

The crypto library are STM32 locked via the CRC peripheral, if that test fails bogus results are delivered.

I'll take a look at the library some more.

[Tesla DeLorean]

Posted on June 01, 2016 at 03:31

Well adapted and tested the F0 code on a NUCLEO-F030R8, adding output via USART2, and compiling in Keil.

Output for the test case appeared to work fine. For good measure I also checked the F4 code on the STM32F407-DISCO

[kesavan]

Posted on September 01, 2016 at 19:30

I had a similar issue with an F4 and eventually fixed it by enabling the CRC module. In my case, it meant calling

RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_CRC, ENABLE);

[Sumir Jha]

Posted on April 12, 2018 at 12:23

Thanks for Your Reply, It solved my Problem