Эта проблема может возникать из-за того, что входные данные имеют другой тип данных, поскольку ни одна из реализаций 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 для декодирования, в зависимости от того, какие языки естественным образом используются в двух местах.В конце концов, шифрование чаще всего используется для связи между двумя местоположениями, а язык, используемый в целевом местоположении, может быть даже неизвестен.