Выбор ключа шифрования из вывода Диффи-Хеллмана

Question

Я реализовал Обмен ключами Диффи-Хеллмана в Java с некоторыми большими группами из RFC 3526 .Мой вывод - довольно большой массив байтов. Безопасно ли использовать первые 448 бит (56 байт) выходных данных для ключа Blowfish? Следует ли каким-либо образом преобразовывать байты или выбирать какие-либо конкретные байты для ключа?

Answer 1

С теоретической точки зрения нет, это небезопасно.Не то чтобы я мог точно определить настоящую атаку;но результатом обмена ключами Диффи-Хеллмана является элемент группы, состоящий из q элементов и обеспечивающий максимальную защиту sqrt (q) .Усечение частей кодирования этого элемента не выглядит хорошей идеей ...

"Правильный" способ заключается в использовании односторонней функции получения ключа.Проще говоря, обработайте вывод Диффи-Хеллмана с хорошей хеш-функцией, такой как SHA-256 , и используйте результат хеширования в качестве ключа.Время хэширования будет незначительным в отношении шага Диффи-Хеллмана.Java уже включает в себя прекрасные реализации SHA-256 и SHA-512, и если вы после совместимости с очень старыми реализациями Java (например, Microsoft JVM, которая шла с Internet Explorer 5.5), то вы можете использовать независимую реализацию Java SHA-2.например, в sphlib .Или, возможно, переопределить его из спецификации (это не сложно): FIPS 180-3 (файл PDF) .

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

Кстати, Blowfish больше не рекомендуется.Он имеет 64-битные блоки, что создает проблемы, когда длина зашифрованных данных достигает нескольких гигабайт, размер, который в настоящее время не так велик.Вам лучше использовать 128-битный блочный шифр, такой как AES .Кроме того, в любой серьезной симметричной системе шифрования вам потребуется проверка целостности ключа.Это можно сделать с помощью MAC (кода аутентификации сообщений), такого как HMAC , который сам построен на основе хеш-функции (опять же, прост в реализации, и в sphlib есть реализация Java).Или, что еще лучше, используйте AES в комбинированном режиме шифрования / MAC, который будет обрабатывать сложные детали для вас (потому что правильно использовать блочный шифр не просто);lookup CWC и GCM (оба не имеют патентов; последний был одобрен NIST).

Answer 2

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

Тем не менее, есть несколько предложений для получения ключа из ключей Диффи-Хеллмана. Например. хорошая статья NIST SP 800-135. Пока это только черновик, и его можно найти здесь . Тем не менее, он рассматривает некоторые существующие стандарты. Конечно, всегда лучше использовать стандарт, чтобы разработать его самостоятельно.

Хотя предложение Томаса Порнина выглядит разумным, оно, тем не менее, является специальным решением. И чтобы быть в безопасности, вы, вероятно, не должны использовать его. Скорее, я бы использовал то, что было проанализировано (например, использование схемы деривации ключей в TLS версии 1.2).