Важность соли при использовании Rfc2898DeriveBytes для создания защищенных паролей из текстовых паролей

Question

Я хотел бы включить шифрование и дешифрование файлов в одном из моих приложений на C# .NET. Сценарий прост: пользователь A отправляет пользователю AES256-зашифрованный файл. Чистый текстовый пароль обменивается на другой канал (например, телефонный звонок или что-то еще).

Из того, что я понимаю, я должен использовать Rfc2898DeriveBytes для преобразования текстового пароля пользователя в более безопасный пароль, используя, возможно, 10 000 раундов. (см. this article).

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

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

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

Answer 1

Соли в контексте хэширования паролей (и деривации ключей) используются для предотвращения предвычисляющих атак, таких как радужные таблицы.

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

Рекомендуемый подход в вашем случае - генерировать случайную соль каждый раз, когда файл зашифрован, и передавать соль вместе с зашифрованным текстом.

Есть ли конкретная причина, по которой вы используете AES-256? Это примерно на 40% медленнее, чем AES-128 из-за дополнительных раундов, и он не предлагает практических преимуществ в области безопасности (особенно в случае шифрования на основе пароля).

Следует также учитывать использование стандартного стандарта, например PGP, а не создание собственного протокола из криптографических примитивов, поскольку создание безопасных протоколов настолько сложно, что даже эксперты не всегда понимают это правильно.

Answer 2

Ваше предположение верно. Если у них есть доступ к паролю, у них также будет доступ к соли. Реализации BCrypt, которые я видел, помещают число итераций, хэш и соль в одной и той же строке результата!

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