Шифрование: использование вектора инициализации против ключа? - PullRequest
18 голосов
/ 24 февраля 2011

Я использую библиотеку PHP mcrypt и алгоритм AES-256 (rijndael), для работы которого требуется как ключ + вектор инициализации.

Мой логический мозг не совсем согласен с этим. Разве не достаточно одного ключа?

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

Следует ли считать ключ более закрытым, чем вектор инициализации, или это так?наоборот?

Ответы [ 4 ]

11 голосов
/ 24 февраля 2011

Нет, на самом деле IV важен в большинстве реализаций.IV также считается безопасным для публичного использования, например, IV передается в виде простого текста для WEP и WPA1 / WPA2.Проблема возникает, когда этот же ключ + iv используется для шифрования того же простого текста.Тексты шифров будут идентичны, если вы не используете IV.Если злоумышленник может зашифровать произвольный простой текст с помощью этого ключа, а затем просмотреть зашифрованный текст.Это гораздо более быстрый способ грубого форсирования другого зашифрованного текста, который получил злоумышленник.

Мало того, IV должен быть случайным, иначе вы нарушите CWE-329 .Причина, по которой это проблема, немного сложнее, и сначала я не понял .Вы не упоминали об этом, но я надеюсь, что вы используете режимы CBC или CMAC

Использование хэш-функции для пароля почти идентично использованию функции String2Key.Это надежный дизайн, если злоумышленник не может использовать SQL-инъекцию для получения ключа.

7 голосов
/ 25 февраля 2011

Не используйте хешированный пароль в качестве единственного источника для ключа и IV.Как правило, вы должны генерировать случайные IV КАЖДЫЙ РАЗ, когда вы обновляете зашифрованные данные и сохраняете IV с этими данными.Ключ можно использовать многократно, но используйте соленое хеширование и сохраняйте соль вместе с данными.

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

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

6 голосов
/ 24 февраля 2011

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

Вы можете посмотреть здесь для хороших диаграмм, показывающих, как и почему используется IV.

0 голосов
/ 12 марта 2015

Если вы используете режим EBP блочного шифра или большинство потоковых шифров, идентичные комбинации ключ + IV на разных открытых текстах предоставят злоумышленникам прямой взгляд на результат XOR ключа. Это по расширению раскрывает сам ключ и в некоторой степени пароль.

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

...