suculent / thinx-aes-lib

AES wrapper for ESP8266/ESP32/Arduino/nRF5x
Other
113 stars 39 forks source link

Not correct result for AES128 #2

Closed prishs closed 5 years ago

prishs commented 5 years ago

it is not giving correct result as expected. I used aes_key[] = { 0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x30} aes_iv[16]= {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0} plaintext[]="AAAAAAAAA" it should give result as 9D6f45lcvhAK2RAbg7CzvQ== but giving result as c4OJpl5ibzzBTToos49SsXk8fPWQAQyfxyRJrl3mNAU= on further debugging I think it is doing wrong padding in method addplaintext. and therefore doing wrong base64 encoding of plaintext.

is someone else getting same wrong result?

suculent commented 5 years ago

This is just a wrapper. padPlaintext is a dependence and it works for me. Should depend on N_BLOCK size which is recalculated on doaes...

Also, the base64 conversion happens twice. Once for converting input string to data, then for encapsulating encrypted data as string for easier transport/debugging.

Same with decryption, input data are first decoded from base64 to binary, then decrypted and then decoded from base64 to string.

suculent commented 5 years ago

So i've introduced explicit encode/decode and encode64/decode64 functions, that work with/without additional B64 encoding for transport on aes64 branch. Let me know if that works for you, please.

Seems like the issue you've mentioned is here:

int paddedLen = msgLen + (N_BLOCK - (msgLen % N_BLOCK)) + 1;  // crashes without +1

It should pad "AAAAAAAAA" (9 bytes) to 16 bytes, but the trailing byte is added because it crashes otherwise.

prishs commented 5 years ago

Seems like the issue you've mentioned is here:

int paddedLen = msgLen + (N_BLOCK - (msgLen % N_BLOCK)) + 1; // crashes without +1

It should pad "AAAAAAAAA" (9 bytes) to 16 bytes, but the trailing byte is added because it crashes otherwise. yes.. from what i could understood.. issue seems to be there.. i could not run base64_iv.ino as it kept crashing..

suculent commented 5 years ago

So the +1 seems to be really required (even after changing badding to all-zeroes), however I was able to shorten the response to meaningful length by padding it after the Base64 encoding.

byte aes_key[] = { 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30 };
byte aes_iv[N_BLOCK] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
Cleartext: AAAAAAAAA
Ciphertext: jVbS6yqmtBcJxpXz3Y6pHg==

Would this work for you? It's in the aes256 branch, simple example.

suculent commented 5 years ago

Fixed in 1.0.3: https://github.com/suculent/thinx-aes-lib/commit/8a6a983c7728a9b9e611fe6d7585650428cde770