В этом вопросе рассматривается добавление запоминающегося текста, такого как «ключ шифрования», в ключ AES путем добавления нулевых байтов к выражению (UTF-8) этого текста в виде байтов до достижения 16, 24 или 32 байтов для AES-128, AES-192, или АЕС-256.
главный проблема в том что это быстро и недорого, что является катастрофой в контексте: он позволяет злоумышленнику быстро и недорого применить этот процесс к правдоподобным паролям и проверить полученные ключи на соответствие зашифрованному тексту (с известным или известным избыточным открытым текстом) и, таким образом, найти ключ. Это взлом пароля, и существует небольшая индустрия, разрабатывающая для этого сочетания программного и аппаратного обеспечения.
Я думаю, что словарь из миллиона наиболее распространенных английских слов (для некоторого расширенного определения слова) будет содержать «ключ шифрования». По крайней мере, поиск в Google обнаружил 78 400 вхождений, и он есть в списке зарегистрированных доменов в трех распространенных TLD. С известной парой открытый текст/зашифрованный текст или зашифрованным текстом для открытого текста с некоторой структурой это займет несколько секунд, чтобы взломать его для кого-то с правильными инструментами.
Несмотря на то, что это можно значительно улучшить (см. следующий абзац), «шифровальный ключ» не является хорошим паролем. Желательно выбрать пароль, который труднее угадать. Просто называя это парольная фраза поможет! Но это вторичный проблема.
При превращении чего-либо запоминающегося (пароль, кодовая фраза...) в ключ, один должен используйте функцию получения ключа, предназначенную для паролей, то есть функцию с параметром workfactor, позволяющим настроить стоимость получения ключа. Если эта стоимость составляет 0,5 секунды времени мощного компьютера, а не 20 наносекунд для предлагаемого метода, это станет узким местом для взлома пароля и, вероятно, заставит их по крайней мере попотеть. С парольной фразой а-ля XKCD или же посуда, это может быть вполне безопасно.
Следует использовать соль, что предотвратит вычисление производных ключей заранее и предотвратит амортизацию стоимости таких производных для нескольких пар пароль/ключ. это еще один вторичный проблема.
Важно, чтобы функция получения ключа требовательна к памяти, то есть использовала значительный объем памяти во время своих вычислений, поскольку это значительно увеличивает денежные затраты на атаку при небольших затратах для законных пользователей. Рекомендуемые функции включают Аргон2 и скрипт. Общие, но не рекомендуемые функции включают ПБКДФ2, который не требует больших объемов памяти и является одним из худших возможных вариантов использования процессорного времени для получения пароля к ключу: он максимизирует преимущество злоумышленников, использующих ASIC, FPGA и даже графические процессоры по сравнению с другими. законные пользователи, использующие процессоры. я нахожу Рекомендация NIST для PBKDF2 в соответствии с их прежним стремлением к Dual_EC_DRBG:
Хотя PBKDF2 требовательна ко времени, но не к памяти, она настолько широко распространена, что нецелесообразно (во всяком случае, в настоящее время) вводить требование для функции получения ключей, требующей памяти.
