Клиент недавно прислал мне криптоспецификацию, которая включала, как бы сказать, неоптимальное использование криптопримитивов. Они пользователи .Net, поэтому я решил поискать хорошую ссылку на криптографию msdn, чтобы их прояснить. Вместо этого я нашел вероятного виновника их замешательства.

Речь идет о статье Как зашифровать и расшифровать файл с помощью Visual C # (с тех пор отменена, победа!). Если вы хотите похлопать по лбу, рекомендую это прочитать. Вот несколько забавных, если не грустных советов, которые я нашел:

Использование DES для шифрования

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

Предложение использовать ключ шифрования в качестве IV

Это был первый в серии данных, которые предполагают, что автор понятия не имеет, что такое IV и как его предполагается использовать. Это предложение на самом деле встречается не раз в статье, вот оскорбительные отрывки:

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

Обратите внимание, что здесь нет упоминания об использовании функции получения ключа, просто предлагается использовать пароль напрямую.

DES.Key = ASCIIEncoding.ASCII.GetBytes(sKey);
DES.IV = ASCIIEncoding.ASCII.GetBytes(sKey);

Этот отрывок, вероятно, даже хуже, поскольку это настоящий код, который ничего не подозревающие читатели потенциально могут скопировать и вставить.

Совет против использования библиотечных ключей и функций генерации IV

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

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

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

IV не включен в зашифрованный текст

Это тонкий, потому что вам нужно либо действительно следовать логике, либо попробовать запустить код самостоятельно. Это, вероятно, объясняет, почему автор рассматривает IV как еще один секретный ключ.

Ссылки также ошибаются с IV

Может показаться, что я действительно разгребаю этого парня до ушей за его непонимание того, что такое капельница и как ее используют; в конце концов, это не статья о режимах блочного шифрования или криптографических ключах, и даже ссылка на ссылку конкретно о криптографических ключах. Конечно, это все проясняет, верно? Верно?? Это буквально второе предложение в этой статье:

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

Но, по крайней мере, в этой статье в их примере используется тройной DES.

Продолжение: Уважаемая Microsoft, вот как можно зашифровать файл