AnsweredAssumed Answered

LPC18S37 - AES engine encrypts differently than Python library.

Question asked by on Jul 8, 2020
Latest reply on Jul 9, 2020 by



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 :





//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_Operate((uint8_t *)TX_ciphertext, (uint8_t *)RX_plaintext, 1);


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