Почему мне нужно использовать класс Rfc2898DeriveBytes (в .NET) вместо прямого использования пароля в качестве ключа или IV?

Question

В чем разница между использованием Rfc2898DeriveBytes и просто использованием Encoding.ASCII.GetBytes(string object);?

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

Основная концепция, которую я смог понять, заключается в том, что вы можете преобразовать строковые пароли в байтовые массивы, которые будут использоваться, например, для класса симметричного шифрования, AesManaged.Через класс RFC, но вы можете использовать солт-значения и пароль при создании вашего объекта rfc.Я предполагаю, что это более безопасно, но в лучшем случае это необразованное предположение!Кроме того, он позволяет вам возвращать байтовые массивы определенного размера, ну что-то в этом роде.

Вот несколько примеров, чтобы показать вам, откуда я:

byte[] myPassinBytes = Encoding.ASCII.GetBytes("some password");

или

string password = "P@%5w0r]>";
byte[] saltArray = Encoding.ASCII.GetBytes("this is my salt");
Rfc2898DeriveBytes rfcKey = new Rfc2898DeriveBytes(password, saltArray);

Объект 'rfcKey' теперь можно использовать для настройки свойств .Key или .IV в классе симметричного алгоритма шифрования.

т.е.

RijndaelManaged rj = new RijndaelManaged ();
rj.Key = rfcKey.Getbytes(rj.KeySize / 8); 
rj.IV = rfcKey.Getbytes(rj.Blocksize / 8);

'rj' должен быть готов к работе!

Запутанная часть ... поэтому вместо использования объекта 'rfcKey' я могу не просто использовать свой массив 'myPassInBytes' дляпомогите настроить мой объект 'rj'?

Я попытался сделать это в VS2008, и немедленный ответ - НЕТ.Но вы, ребята, получили более образованный ответ о том, почему класс RFC используется по сравнению с другой альтернативой, которую я упомянул выше?

Answer 1

Вы действительно, действительно, не хотите использовать пароль пользователя непосредственно в качестве ключа шифрования, особенно с AES.

Rfc2898DeriveBytes является реализацией PBKDF2. Он постоянно хеширует пароль пользователя вместе с солью. Это имеет несколько преимуществ:

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

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

Несколько итераций (по умолчанию 1000) замедляют атаки по подбору пароля. Рассмотрим кого-то, кто пытается угадать ваш ключ AES. Если вы просто использовали пароль, это было бы просто - просто попробуйте каждый возможный пароль в качестве ключа. С другой стороны, в PBKDF2 злоумышленник сначала должен выполнить 1000 итераций хеша для каждой попытки угадать пароль. Таким образом, хотя он лишь немного замедляет пользователя, он оказывает непропорциональное влияние на злоумышленника. (На самом деле довольно часто используется гораздо большее число итераций; обычно рекомендуется 10000).

Это также означает, что окончательный выходной ключ распределен равномерно. Например, если вы использовали пароль, обычно 16 из 128 битов ключа были бы 0 (старший бит ASCII). Это сразу же делает поиск ключей в 65536 раз проще, чем следовало бы, даже игнорируя угадывание пароля.

Наконец, у AES есть определенные уязвимости с соответствующими ключевыми атаками. Атаки по связанному ключу возможны, когда злоумышленнику известны некоторые данные, зашифрованные несколькими ключами, и между ними существует известная (или предполагаемая) связь. Например, если вы зашифровали данные как с помощью пароля-пароля «Мой ключ AES сосет» (16 байт, для AES-128), так и с «MY AES KEY SUCKS», возможна атака по связанному ключу. Наиболее известные в настоящее время атаки фактически не позволяют таким образом полностью взломать AES, но со временем они постепенно улучшаются - только на прошлой неделе была опубликована новая атака, которая разбивает 13 раундов (из 14 общих) AES-256 с использованием связанная ключевая атака. Было бы крайне неразумно полагаться на то, что такие атаки не улучшатся со временем.