LPC18S37 - AES engine encrypts differently than Python library.

[can_pouliquen]

Hello,

I am trying to use the AES engine of the LPC18S37 in ECB-mode to encrypt a 16-bytes plaintext. I obtain a ciphertext, which I then take through the decryption process to verify that I get the same original plaintext, which I do. 

However, as a safety measure, I also desired to verify using an external resource, and therefore encrypted the same plaintext using a Python API (Crypto.Cipher.AES) in ECB-mode) but I didn't get the same ciphertext as from the MCU. The problem is that when I decrypt the Python version of the ciphertext, result is the same original plaintext.

I verified the lib's algorithm implementation, comparing it to the FIPS-197 standard : It is properly implemented.

I therefore assume that the problem most likely comes from my implementation of the code in the MCU.

I took of course care of verifying that the keys and plaintexts were strictly the same in both scenarios.

If anybody has advices or knows how to solve the problem, I would gladly welcome any ideas.

Thank you in advance.

Here are the relevant parts of the implementation of the MCU program :

Board_Init();

Chip_AES_Init();

//Set buffers :
        uint8_t RX_plaintext[16]; / /Contains a 16-bytes plaintext
        uint8_t TX_plaintext[16]; // WILL contain a 16-bytes plaintext after decryption
        uint8_t RX_key[16]; // Contains a 16-bytes key
        uint8_t TX_ciphertext[16]; // WILL contain the 16-bytes ciphertext after encryption

         ...

Chip_AES_LoadKeySW((uint8_t *) RX_key); // I like using verbose casts but this works the same way even without them

Chip_AES_SetMode(CHIP_AES_API_CMD_ENCODE_ECB);
Chip_AES_Operate((uint8_t *)TX_ciphertext, (uint8_t *)RX_plaintext, 1);

Chip_AES_SetMode(CHIP_AES_API_CMD_DECODE_ECB);
Chip_AES_Operate((uint8_t *)TX_plaintext, (uint8_t *)TX_ciphertext, 1);

[can_pouliquen]

I fixed it :-)

If anyone encounters a similar problem someday : it had to do with the way data was processed by the AES engine. The array was processed from the opposite sides between the MCU (which had a hardware AES engine) and the Python script (which had a software implementation).

The way the data is processed can't changed, so flipping the key and plaintext buffers before processing by the MCU and the flipping them again after encryption did the trick.