LPC43S37 AES ECB mode

[lpcware]

Content originally posted in LPCWare by bin.er on Thu Oct 08 20:59:12 MST 2015
I tried to encode AES 128 ECB test vendor and check the result, and the result is not as expected.
I am wondering the use of AES API of LPC43S37.

Test vector are
uint8_t key[] = {0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6, 0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c};
uint8_t plain_text[]  = {0x6b, 0xc1, 0xbe, 0xe2, 0x2e, 0x40, 0x9f, 0x96, 0xe9, 0x3d, 0x7e, 0x11, 0x73, 0x93, 0x17, 0x2a};
uint8_t out[] = {0x3a, 0xd7, 0x7b, 0xb4, 0x0d, 0x7a, 0x36, 0x60, 0xa8, 0x9e, 0xca, 0xf3, 0x24, 0x66, 0xef, 0x97};
        uint32_t i = 0;
Chip_AES_Init();
Chip_AES_LoadKeySW(key);
//Chip_AES_LoadIV_SW(iv);// no initial IV is required as ECB mode
ret = Chip_AES_SetMode(CHIP_AES_API_CMD_ENCODE_ECB);
Chip_AES_Operate(&compressed_text, &plain_text, 16); //also 1 was tried as 3rd argument
The compressed_text is not consistent with the expected result, thought it can be decrypted well by AES ECB engine of LPC43S37 ECB mode and recover the plain text.
compressed_text0x10000050uint8_t[64]
[0]0xB30x10000050uint8_t
[1]0xAE0x10000051uint8_t
[2]0x6C0x10000052uint8_t
[3]0xBF0x10000053uint8_t
[4]0xDD0x10000054uint8_t
[5]0x60        0x10000055uint8_t
[6]0xD70x10000056uint8_t
[7]0x5C0x10000057uint8_t
[8]0xEA0x10000058uint8_t
[9]0x0D0x10000059uint8_t
[10]0xBC0x1000005Auint8_t
[11]0xA20x1000005Buint8_t
[12]0x54   0x1000005Cuint8_t
[13]0x0E0x1000005Duint8_t
[14]0xB00x1000005Euint8_t
[15]0xED0x1000005Fuint8_t

[lpcware]

Content originally posted in LPCWare by bin.er on Sun Oct 11 19:10:48 MST 2015
No hardfault and no re-initialization is required. The question can be closed.
Thank you

Chip_AES_Init();
Chip_AES_LoadKeySW(key);
ret = Chip_AES_SetMode(CHIP_AES_API_CMD_ENCODE_ECB);
while(i < sizeof(plain_text)) {
Chip_AES_Operate(&compressed_text, &plain_text, 1);
i+=16;
}

[lpcware]

Content originally posted in LPCWare by bin.er on Sat Oct 10 05:57:08 MST 2015
Here is the wiki page for you
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

ECB mode is insecure as it is one time pad cypher. For example, you have two 16 Bytes message to encode with same key, m0 and m1, assume they are same. m0 == m1
Using ECB mode, the cypher text is same and you can get c0 == c1.
Thus, anyone knows m0 can understand m1 without decrypt c1, when he has c0, c1 and finds c0 == c1

Counter mode , CBC mode and others involve an initialize vector such that the c0 and c1 is different when m0 and m1 encrypt with same key. The encryption is secure if the vector is not repeated.

[lpcware]

Content originally posted in LPCWare by bin.er on Sat Oct 10 05:47:03 MST 2015
Thank you.
The comment mentions
* @paramSize: Size of the data stream (128-bit)
I will try the argument '1' to encrypt 16 Bytes next week.

The usage is different to some software library for encryption like crypto c++ and mini-AES.
The ROM API interprets the input plain text stream as "array" of 128 Bytes little endian block, and use the element number as parameters, though the function signature is uint8_t
uint32_t Chip_AES_Operate(uint8_t *pDatOut, uint8_t *pDatIn, uint32_t Size);

The programming language is not easy to declare a 128bits variable for key and a text for little endian 128 bits.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Fri Oct 09 05:33:44 MST 2015
I know nothing about encryption, but I see from another forum that I frequent that ECB mode is considered 'rubbish/insecure'
and that CTR mode should be used.

I don't know what this means or implies, but it might give you a point for a Google search.

Cheers, Mike.

[lpcware]

Content originally posted in LPCWare by DF9DQ on Fri Oct 09 04:25:17 MST 2015
Not sure why you see a hard fault. I can try out on real hardware next week if you send me a test project.

Is the call to Chip_AES_Operate() correct? The last parameter (16) tells the function to process 16 blocks of 16 bytes each. Maybe the intention is to process 16 bytes only, which requires to set this parameter to 1.

[lpcware]

Content originally posted in LPCWare by bin.er on Fri Oct 09 02:29:27 MST 2015
Thanks Rolf. You are right.
I got the same result as expected.

May I have another question about the consecutive AES ECB execution.
I find that I should call the following sequence recursively in the while loop. eg in counter mode, you need to encrypt the IV per block and ch
while(1) {
Chip_AES_Operate(&IV,&encIV, 16);
/* re-init is necessary */
Chip_AES_Init();
Chip_AES_LoadKeySW(key);
ret = Chip_AES_SetMode(CHIP_AES_API_CMD_ENCODE_ECB);
                ...
}
i tried to remove the re-initialization code and hard fault happens and the key loading is also necessary though the key is same

[lpcware]

Content originally posted in LPCWare by DF9DQ on Fri Oct 09 00:55:16 MST 2015
Hi Bin,
The existing AES ROM API expects all input (key, IV, cipher/plain) to be in little endian format, and the result (plain/cipher) is in little endian as well.
So can you try with this input:

uint8_t key[] = {0x3c, 0x4f, ... 0x7e, 0x2b};
uint8_t plain_text[] = {0x2a, 0x17, ... 0xc1, 0x6b};

I have no hardware to test this at the moment, but I expect the result to be

uint8_t out[] = {0x97, 0xef, ... 0xd7, 0x3a};

Regards, Rolf