esp32 and php XXTEA strings encryption

Question

I'm using esp32 (Arduino platform not esp-idf) with the "HTTPClient.h" library to send get requests with parameters to my PHP server.

I want to encrypt the parameter values and decrypt them in my PHP code And vice versa (my server sends back JSON data to my esp32).

I tried using the XXTEA protocol with these libraries for PHP, and for esp32.

But the encrypted string won't decrypt properly on PHP.

Example:

When I encrypt "HELLO WORLD" on my esp32 with the key "ENCRYPTION KEY" I get this:

35bd3126715874f741518f4d

And when I decrypt it on PHP it returns blank.

Moreover, when I encrypt it on my PHP server I get this:

T1YNYC4P4R2Y5eCxUqtjuw==

My esp32 sketch looks like this:

#include <xxtea-iot-crypt.h>

void setup() {
  Serial.begin(115200);
}

void loop() {
  String plaintext = "HELLO WORLD";

  // Set the Password
  xxtea.setKey("ENCRYPTION KEY");

  // Perform Encryption on the Data
  Serial.print(F(" Encrypted Data: "));
  String result = xxtea.encrypt(plaintext);

  Serial.println(result);

  // Perform Decryption
  Serial.print(F(" Decrypted Data: "));
  Serial.println(xxtea.decrypt(result));
  delay(2000);

}

My PHP code looks like this:

require_once('xxtea.php');
$str = "HELLO WORLD"
$key = "ENCRYPTION KEY";
$encrypt_data = xxtea_encrypt($str, $key);
error_log($encrypt_data);

Is there a way to have an encrypted strings communication between PHP and esp32?

Thanks in advance.

Answer 1

Why not using the wificlientsecure library? Works great on the esp32.

Answer 2

This problem may result from inputs being of different data type, since no current XXTEA implementation seems to do any type or range checking.

Or it could be due to different endian behavior of the two computers involved, since binary is typically stored as an array of words constructed from bytes.

Or it could be due to lack of official or standard reference examples for correct encryption of a specific string and key. In the absence of reference examples (using either hexadecimal or base64 conversion of the binary encryption result) there is no way to tell whether an implementation of encryption is correct, even if its results decrypt correctly using a corresponding decryption implementation.

ADDED:

I think I've found one compatibility problem in the published code for XXTEA. It may be worth taking some space here to discuss it.

Specifically, the problem is that different implementations create different results for encrypting the same plaintext and key.

Discussion:

This problem results from the addition of the length of the plaintext as the last element of the array of longs. While this solves the problem of plaintext that has a length that is not a multiple of 4, it generates a different encrypted value than is generated by the JavaScript implementation.

If you insert "$w=false;" at the start of the long2str and str2long functions, the encrypted value for the PHP implementation becomes the same as the JavaScript implementation, but the decrypted value has garbage at the end.

Here are some test case results with this change:

PHP:

text:    >This is an example. !@#$%^&*(){}[]:;<
Base64:  PlRoaXMgaXMgYW4gZXhhbXBsZS4gIUAjJCVeJiooKXt9W106Ozw=
key:     8GmZWww5T97jb39W
encrypt: sIubYrII6jVXvMikX1oQivyOXC07bV1CoC81ZswcCV4tkg5CnrTtqQ==
decrypt: >This is an example. !@#$%^&*(){}[]:;<��

Note: there are two UTF-8 question-mark characters at the end of the "decrypt" line.

JavaScript:

text:    >This is an example. !@#$%^&*(){}[]:;<
Base64:  PlRoaXMgaXMgYW4gZXhhbXBsZS4gIUAjJCVeJiooKXt9W106Ozw=
key:     8GmZWww5T97jb39W
encrypt: sIubYrII6jVXvMikX1oQivyOXC07bV1CoC81ZswcCV4tkg5CnrTtqQ==
decrypt: >This is an example. !@#$%^&*(){}[]:;<

The reason there is no garbage in the JavaScript implementation even though it does not save the length of the plaintext is given in a comment there: "note running off the end of the string generates nulls since bitwise operators treat NaN as 0". In other words, the generated string is padded with NULs that are never seen, even though JavaScript, like PHP, can include NULs in strings because it stores the length separately.

I don't have an opinion about which approach is best, but one should be chosen for all implementations.

The reason that there should be a standard for the result of encryption (regardless of whether the binary is converted to hex or to base64 for safe transit) is that one might want to use, say, PHP for encoding but JavaScript for decoding, depending on which languages are natural to use at two locations. After all, encryption is most often used to communicate between two locations, and the language used at the target location might not even be known.