Шифрование AES - ключ против IV

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

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

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

Я вижу три варианта создания ключевого файла:

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

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

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

Ответ 1

Как вы можете видеть из других ответов, наличие уникального IV за зашифрованный файл имеет решающее значение, но почему это?

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

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

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

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

Итак, теперь давайте рассмотрим предлагаемые вами варианты:

Вариант 1. Вставьте жестко закодированный IV внутри приложения и сохраните ключ в файле ключа.

Вариант 2. Вставьте жестко закодированный ключ в приложение и сохраните IV в файле ключа.

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

Вариант 3. Сохраните ключ и IV в файле ключа.

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

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

Ответ 2

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

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

Если вы собираетесь переводить свои собственные способы шифрования, пожалуйста, ознакомьтесь с соответствующими стандартами. В NIST есть хороший документ о режимах шифрования: http://dx.doi.org/10.6028/NIST.SP.800-38A IV поколение описано в Приложении C. Криптография - это тонкое искусство. Не поддавайтесь соблазну создавать вариации в режимах обычного шифра; 99% времени вы создадите что-то более безопасное, но на самом деле менее безопасно.

Ответ 3

Когда вы используете IV, самое главное, что IV должен быть как можно более уникальным, поэтому на практике вам следует использовать случайный IV. Это означает, что вложение его в ваше приложение не является вариантом. Я бы сохранил IV в файле данных, так как он не навредил безопасности , пока IV является случайным/уникальным.