AES делят только ключ (без соли или IV) - PullRequest
0 голосов
/ 21 ноября 2018

У меня есть требование зашифровать с помощью AES -симметричной строки, а затем поделиться зашифрованной строкой с клиентом.

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

Однако все реализации Java, которые я обнаружил, требуют передачи соли (или IV) вместе с зашифрованным документом.Это лишает смысла разделять только зашифрованный текст и симметричный ключ (перед раздачей), если мне как-то придется каждый раз посылать соль.

Я что-то не так понимаю?Есть ли способ поделиться только зашифрованным текстом и симметричным ключом?

Ответы [ 2 ]

0 голосов
/ 21 ноября 2018

Обычно IV передается путем добавления его к зашифрованному тексту.Итак, в конце концов вы отправляете одну строку в кодировке Base64.

Итак, если вы беспокоитесь о том, чтобы разорвать контракт, отправив два поля (один IV и один зашифрованный текст) вместо отправки только одного поля, позвольте мне заверить вас, что вы собираетесь отправить только одно поле,И логика дешифрования знает, как извлечь IV из полученной строки и использовать его в процессе расшифровки.

Обратите внимание, что между IV и ключом есть некоторые ключевые различия:

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

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

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

Если только получатель (в вашем случае) не указывает жестко конкретный режим для AES, по умолчанию всегда будет AES с GCM.И даже если получатель предлагает какой-либо режим, который не является режимом аутентифицированного шифрования, вы можете объяснить ему преимущества использования режима аутентифицированного шифрования.

Вы найдете полную реализацию Java с подробным объяснением здесь .

Вы также можете прочитать это вместе с комментариями, чтобы лучше это понять.

0 голосов
/ 21 ноября 2018

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

E(k,m) = E(k,m') iff m=m'

В современных режимах работы используется IV, в качестве AES-GCM, который находится в комплектах шифров TLS 1.3.

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

Примечание: режим ECB может быть безопасным, только если

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