Шифрование строк esp32 и php XXTEA - PullRequest
0 голосов
/ 13 сентября 2018

Я использую esp32 (платформа Arduino, а не esp-idf) с библиотекой "HTTPClient.h" для отправки запросов на получение параметров с моим PHP-сервером.

Я хочу зашифровать значения параметров и расшифровать их вмой PHP-код и наоборот (мой сервер отправляет обратно данные JSON на мой esp32).

Я пытался использовать протокол XXTEA с этими библиотеками для PHP и для esp32 .

Но зашифрованная строка не будет правильно расшифровываться на PHP.

Пример:

Когда я шифрую "HELLO WORLD" на моем esp32 с помощью ключа "ENCRYPTION KEY" Я получаю это:

35bd3126715874f741518f4d

И когда я расшифровываю его на PHP, он возвращается пустым.

Более того, когда я шифрую его намой сервер PHP я получаю это:

T1YNYC4P4R2Y5eCxUqtjuw==

Мой эскиз esp32 выглядит так:

#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);

}

Мой код PHP выглядит следующим образом:

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

Есть ли способ иметь зашифрованные строки для связи между PHP и esp32?

Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 25 октября 2018

Эта проблема может возникать из-за того, что входные данные имеют другой тип данных, поскольку ни одна из реализаций XXTEA, по-видимому, не выполняет какую-либо проверку типа или диапазона.

Или это может быть из-за разного порядка следования двух участвующих компьютеров,поскольку двоичный файл обычно хранится в виде массива слов, составленного из байтов.

Или это может быть связано с отсутствием официальных или стандартных справочных примеров для правильного шифрования конкретной строки и ключа.В отсутствие эталонных примеров (с использованием шестнадцатеричного или base64 преобразования двоичного результата шифрования) невозможно определить, правильна ли реализация шифрования, даже если его результаты правильно расшифрованы с использованием соответствующей реализации дешифрования.

ДОБАВЛЕНО:

Мне кажется, я нашел одну проблему совместимости в опубликованном коде для XXTEA.Возможно, стоит обсудить это здесь.

В частности, проблема в том, что разные реализации создают разные результаты для шифрования одного и того же открытого текста и ключа.

Обсуждение:

Эта проблема возникает из-за добавления длины открытого текста в качестве последнего элемента массива long.Хотя это решает проблему с открытым текстом, длина которого не кратна 4, он генерирует зашифрованное значение, отличное от того, которое создается реализацией JavaScript.

Если вставить «$ w = false;»в начале функций long2str и str2long зашифрованное значение для реализации PHP становится таким же, как и реализация JavaScript, но в конце дешифрованное значение содержит мусор.

Вот некоторые результаты теста с этим изменением:

PHP:

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

Примечание: в конце строки «расшифровать» есть два знака вопроса UTF-8.

JavaScript:

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

Причина, по которой в реализации JavaScript нет мусора, даже если он не сохраняет длину открытого текста, приведена в комментарии там: «примечание, начинающееся с конца строки, генерирует нули, поскольку побитовые операторы обрабатываютNaN как 0 ".Другими словами, сгенерированная строка дополняется NUL, которые никогда не видны, хотя JavaScript, как и PHP, может включать NUL в строки, потому что он хранит длину отдельно.

У меня нет мнения о том, какиеподход является лучшим, но его следует выбирать для всех реализаций.

Причина, по которой должен быть стандарт для результата шифрования (независимо от того, преобразован ли двоичный файл в шестнадцатеричный или в base64 для безопасного транзита)что можно использовать, скажем, PHP для кодирования, но JavaScript для декодирования, в зависимости от того, какие языки естественным образом используются в двух местах.В конце концов, шифрование чаще всего используется для связи между двумя местоположениями, а язык, используемый в целевом местоположении, может быть даже неизвестен.

0 голосов
/ 13 сентября 2018

Почему бы не использовать библиотеку wificlientsecure ? Отлично работает на esp32.

...