Шифрование: Использование вектора инициализации против ключа?
Я использую библиотеку PHP mcrypt и алгоритм AES-256 (rijndael), для запуска которого требуется как ключ, так и вектор инициализации.
Моя логическая сторона ума на самом деле не согласна с этим. Разве недостаточно одного ключа?
Теоретический сценарий:
Если бы у меня были зашифрованные конфиденциальные данные, хранящиеся в базе данных, которые должен иметь возможность расшифровать только владелец, было бы целесообразно использовать хэшированный пароль пользователей либо для ключа, либо для инициализации вектор к его или ее данным?
Следует ли считать ключ более закрытым, чем вектор инициализации, или все наоборот?
4 answers
Нет, на самом деле капельница жизненно важна в большинстве реализаций. IV также считается безопасным для общественного использования, например, IV передается в виде простого текста для WEP и WPA1/WPA2. Проблема возникает, когда один и тот же ключ+iv используется для шифрования одного и того же простого текста. Зашифрованные тексты будут идентичны, если вы не используете капельницу. Если злоумышленник может зашифровать произвольный простой текст с помощью этого ключа, а затем просмотреть зашифрованный текст. Это гораздо более быстрый способ грубого форсирования другого зашифрованного текста, который злоумышленник получил.
Не только это, IV должен быть случайным, иначе вы нарушили бы CWE-329. Причина, по которой это проблема, немного более тонкая, и Я не понял ее сначала. Вы не упомянули об этом, но я надеюсь, что вы используете режимы CBC или CMAC
Использование хэш-функции для пароля почти идентично использованию функции String2Key. Это надежная конструкция до тех пор, пока злоумышленник не сможет использовать SQL-инъекцию для получения ключ.
Не используйте хэшированный пароль в качестве единственного источника для ключа и IV. Как правило, вы должны генерировать случайные IV КАЖДЫЙ раз, когда обновляете зашифрованные данные, и хранить IV с этими данными. Ключ можно использовать несколько раз, но используйте соленое хеширование и храните соль вместе с данными.
Если вы просто хэшируете пароли пользователей и используете их в качестве ключей шифрования, пользователи с одинаковыми паролями будут иметь одинаковые ключи. В зависимости от структуры вашей базы данных и прав доступа злоумышленника могут возникнуть некоторые неприятные случаи, когда могут быть обнаружены пользователи с одинаковыми паролями. Добавьте по крайней мере уникальное имя пользователя к этому хэшу.
Если вы не изменяете IV для каждого обновления данных, информация об изменениях данных может быть утечка. В режиме CBC или CFB идентичные первые блоки открытого текста будут зашифрованы в идентичный зашифрованный текст до первого изменения открытого текста, поэтому положение этого изменения может быть определено.
Вектор инициализации (IV) вообще не является ключом и не является секретным. На самом деле, он часто раскрывается (например, добавляется к зашифрованным данным). Он используется в качестве дополнительного случайного ввода в алгоритм шифрования, так что результат шифрования одних и тех же четких данных будет отличаться каждый раз, когда вы используете другой IV. Таким образом, статистика не может быть собрана по зашифрованным данным. Это само по себе не "улучшает" надежность шифрования.
Вы можете посмотреть здесь для хороших диаграмм показывая, как и почему используется внутривенное вливание.
Если вы используете режим EBP блочного шифра или большинство потоковых шифров, идентичные комбинации ключ+IV в разных открытых текстах предоставят злоумышленникам прямой доступ к результату XOR ключа. Это, в свою очередь, раскрывает сам ключ и в некоторой степени пароль.
Но имею ли я в виду, что капельницы определенно необходимы? Нет. Пока вы каждый раз меняете свой пароль в следующем блоке открытого текста (даже в том же блоке во второй раз), вы в полном порядке без капельниц. Фактически, все, что делает IV, - это автоматизация вышеупомянутого процесса.