API шифрования Java против различных платформ - PullRequest
2 голосов
/ 17 июля 2011

У меня есть приложение Android, которое использует javax.crypto для шифрования некоторых текстовых данных в файлах. Реализация шифрования аналогична this . Приложение отлично работает с ранее зашифрованными данными.

Теперь я почти перенес приложение для Android на рабочий стол (JFace / SWT). Я использую ту же реализацию шифрования для перенесенного приложения, поскольку она не зависит от какого-либо специфичного для Android API. Портированное приложение прекрасно работает с созданными им зашифрованными данными.

Проблема в том, что настольное приложение не может расшифровать данные, которые были сохранены с помощью приложения Android. Приложение Android не может расшифровать данные, которые также были сохранены в приложении для ПК. Я дважды проверил байты потоков простых данных и пароля для шифрования на обеих платформах. Они одинаковые, поэтому с кодировкой текста проблем не возникает. Но процедура шифрования возвращает разные зашифрованные результаты на разных платформах, даже если входные данные идентичны между байтами.

Гарантирует ли Java crypto API одинаковую работу на разных платформах? Должен ли поставщик шифрования (AES / 128bit в моем случае) работать одинаково на Android, Linux и Windows? Есть ли способ настроить javax.crypto для обеспечения взаимодействия на разных платформах?

Ответы [ 3 ]

4 голосов
/ 17 июля 2011

AES-128 должен работать одинаково на обеих системах.Теоретически.

На практике существует множество деталей, которые должны быть одинаковыми в обеих системах.

  • Вы используете одинаковые отступы с обеих сторон?
  • Вы используете один и тот же режим (CBC, CTR, ECB) с обеих сторон?
  • у вас есть точно один и тот же пароль с обеих сторон?
  • выУ вас одинаковый IV / Nonce с обеих сторон?
  • У вас есть одинаковый метод получения ключа с обеих сторон?

Проверьте все значения по умолчанию в обеих системах.Если значения по умолчанию не совпадают, вам нужно явно указать одну или другую сторону.

3 голосов
/ 17 июля 2011

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

Один из способов, которым эти соли часто передаются, - это префикс в зашифрованном тексте.Это делает зашифрованный текст длиннее, чем открытый текст, но я не думаю, что это имеет значение в вашей методике выборки.

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

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

Запоздалая мысль: То, что происходит в текущем подходе, заключается в том, что криптографически полезный ГСЧ используется таким образом, что вся случайность была удалена!Рекомендация проверить PBKDF2 и вывод ключа в целом является хорошей.

0 голосов
/ 17 июля 2011

Вы должны показать нам некоторый код. Одна из частых ошибок новичка - хранить зашифрованные данные в String, а не в байте [], в который они вошли. String не является контейнером для двоичных данных. Эта техника может не сработать разными способами, включая различия по шарадам по умолчанию.

...