Как реализовать Java 256-разрядное Шифрование AES с CBC

Вы могли бы хотеть проверить данную статью:

подобие Предложения на основе семантических сетей и корпусной статистики (PDF)

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

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

С уважением,

Matt.

16
задан Community 23 May 2017 в 11:44
поделиться

2 ответа

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

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

Кроме того, вам не следует использовать метод no-arg getBytes () для String . Это зависит от платформы. Если все строки, которые вы кодируете, содержат только символы из набора символов US-ASCII, проясните это, явно указав эту кодировку. В противном случае, если на телефонной и серверной платформах используются разные кодировки символов, ключ и IV не будут одинаковыми.

В режиме CBC лучше всего использовать новый IV для каждого отправляемого сообщения. Обычно IV CBC генерируются случайным образом. Другие режимы, такие как CFB и OFB , требуют уникальных IV для каждого сообщения. IV обычно отправляются вместе с зашифрованным текстом - IV не нужно хранить в секрете, но многие алгоритмы сломаются, если используется предсказуемый IV.

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

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

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


Обновление:

Диффи-Хеллман в «эфемерно-статическом» режиме (и «статико-статическом» "режим тоже, хотя это менее желательно) возможен без начального сообщения с сервера на телефон, если открытый ключ сервера встроен в приложение.

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

Можно использовать статико-статический режим, но на самом деле он более сложный и менее безопасный. Каждому телефону потребуется своя собственная уникальная пара ключей, иначе вы снова столкнетесь с проблемой секретного ключа. По крайней мере, серверу не нужно было бы отслеживать, какой телефон имеет какой ключ (при условии, что на уровне приложения есть какой-то механизм аутентификации, например пароль).

Я не знаю, насколько быстрые телефоны. На моем рабочем столе создание эфемерной пары ключей занимает около 1/3 секунды. Параметры Диффи-Хеллмана генерируются очень медленно; вы обязательно захотите повторно использовать параметры из ключа сервера.

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

Я не знаю, насколько быстрые телефоны. На моем рабочем столе создание эфемерной пары ключей занимает около 1/3 секунды. Параметры Диффи-Хеллмана генерируются очень медленно; вы обязательно захотите повторно использовать параметры из ключа сервера.

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

Я не знаю, насколько быстрые телефоны. На моем рабочем столе создание эфемерной пары ключей занимает около 1/3 секунды. Генерация параметров Диффи-Хеллмана происходит очень медленно; вы обязательно захотите повторно использовать параметры из ключа сервера.

Создание пары эфемерных ключей занимает около 1/3 секунды. Параметры Диффи-Хеллмана генерируются очень медленно; вы обязательно захотите повторно использовать параметры из ключа сервера.

Создание пары эфемерных ключей занимает около 1/3 секунды. Генерация параметров Диффи-Хеллмана происходит очень медленно; вы обязательно захотите повторно использовать параметры из ключа сервера.

12
ответ дан 30 November 2019 в 22:55
поделиться

Раньше выполнял аналогичные проекты в мидлете, у меня для вас есть следующий совет:

  1. Нет безопасного способа хранить общий секрет на телефоне. Вы можете использовать его, но он попадает в категорию под названием Безопасность через неизвестность . Это похоже на защиту типа «ключ под ковриком».
  2. Не используйте 256-битный AES, который не является широко доступным. Возможно, вам придется установить другой JCE. 128-битные AES или TripleDES по-прежнему считаются безопасными. Принимая во внимание №1, вы не должны беспокоиться об этом.
  3. Шифрование с использованием пароля (разного для каждого пользователя) намного безопаснее. Но вы не должны использовать пароль в качестве ключа, как в примере. Пожалуйста, используйте PBEKeySpec (шифрование на основе пароля) для генерации ключей.
  4. Если вас беспокоят атаки MITM (человек посередине), используйте SSL.
2
ответ дан 30 November 2019 в 22:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: