<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>LPC MicrocontrollersのトピックRe: LPC18S37 - AES engine encrypts differently than Python library.</title>
    <link>https://community.nxp.com/t5/LPC-Microcontrollers/LPC18S37-AES-engine-encrypts-differently-than-Python-library/m-p/1080134#M41522</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV class=""&gt;&lt;P&gt;I fixed it :-)&lt;/P&gt;&lt;P&gt;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).&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 09 Jul 2020 09:17:12 GMT</pubDate>
    <dc:creator>can_pouliquen</dc:creator>
    <dc:date>2020-07-09T09:17:12Z</dc:date>
    <item>
      <title>LPC18S37 - AES engine encrypts differently than Python library.</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/LPC18S37-AES-engine-encrypts-differently-than-Python-library/m-p/1080133#M41521</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;I verified the lib's algorithm implementation, comparing it to the FIPS-197 standard : It is properly implemented.&lt;/P&gt;&lt;P&gt;I therefore assume that the problem most likely comes from my implementation of the code in the MCU.&lt;/P&gt;&lt;P&gt;I took of course care of verifying that the keys and plaintexts were strictly the same in both scenarios.&lt;/P&gt;&lt;P&gt;If anybody has advices or knows how to solve the problem, I would gladly welcome any ideas.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thank you in advance.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Here are the relevant parts of the implementation of the MCU program :&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Board_Init();&lt;/P&gt;&lt;P&gt;Chip_AES_Init();&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;//Set buffers :&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;uint8_t RX_plaintext[16]; / /Contains a 16-bytes plaintext&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;uint8_t TX_plaintext[16]; // WILL contain a 16-bytes plaintext after decryption&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;uint8_t RX_key[16]; // Contains a 16-bytes key&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;uint8_t TX_ciphertext[16]; // WILL contain the 16-bytes ciphertext after encryption&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ...&lt;/P&gt;&lt;P&gt;Chip_AES_LoadKeySW((uint8_t *) RX_key); // I like using verbose casts but this works the same way even without them&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Chip_AES_SetMode(CHIP_AES_API_CMD_ENCODE_ECB);&lt;BR /&gt;Chip_AES_Operate((uint8_t *)TX_ciphertext, (uint8_t *)RX_plaintext, 1); &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Chip_AES_SetMode(CHIP_AES_API_CMD_DECODE_ECB);&lt;BR /&gt;Chip_AES_Operate((uint8_t *)TX_plaintext, (uint8_t *)TX_ciphertext, 1);&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 08 Jul 2020 14:24:18 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/LPC18S37-AES-engine-encrypts-differently-than-Python-library/m-p/1080133#M41521</guid>
      <dc:creator>can_pouliquen</dc:creator>
      <dc:date>2020-07-08T14:24:18Z</dc:date>
    </item>
    <item>
      <title>Re: LPC18S37 - AES engine encrypts differently than Python library.</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/LPC18S37-AES-engine-encrypts-differently-than-Python-library/m-p/1080134#M41522</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV class=""&gt;&lt;P&gt;I fixed it :-)&lt;/P&gt;&lt;P&gt;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).&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 09 Jul 2020 09:17:12 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/LPC18S37-AES-engine-encrypts-differently-than-Python-library/m-p/1080134#M41522</guid>
      <dc:creator>can_pouliquen</dc:creator>
      <dc:date>2020-07-09T09:17:12Z</dc:date>
    </item>
  </channel>
</rss>

