Почему я должен использовать класс Rfc2898DeriveBytes (в.NET) вместо того, чтобы непосредственно использовать пароль в качестве ключа или IV?
Каково различие между использованием 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 используется по другой альтернативе, которую я упомянул выше?
1 ответ
Вы действительно, действительно не хотите использовать пароль пользователя непосредственно в качестве криптографического ключа, особенно с AES.
Rfc2898DeriveBytes - это реализация PBKDF2. Она выполняет многократное хэширование пароля пользователя вместе с солью. Это имеет несколько преимуществ:
Во-первых, вы можете использовать пароли произвольного размера - AES поддерживает только определенные размеры ключей.
Во-вторых, добавление соли означает, что вы можете использовать одну и ту же парольную фразу для генерации нескольких различных ключей (при условии, что соль не является константой, как в вашем примере). Это важно для разделения ключей; повторное использование ключей в различных контекстах - один из наиболее распространенных способов взлома криптографических систем.
Множественные итерации (1000 по умолчанию) замедляют атаки на угадывание пароля. Представьте, что кто-то пытается угадать ваш ключ AES. Если бы вы просто использовали пароль, это было бы просто - просто попробуйте каждый возможный пароль в качестве ключа. С другой стороны, при использовании PBKDF2 злоумышленнику сначала придется выполнить 1000 итераций хэша для каждой догадки пароля. Поэтому, хотя это незначительно замедляет работу пользователя, для злоумышленника это имеет непропорционально большой эффект. (На самом деле обычно используются гораздо большие числа итераций; обычно рекомендуется 10000).
Это также означает, что конечный выходной ключ распределен равномерно. Если вы, например, используете пароль, то обычно 16 из 128 битов ключа будут равны 0 (старший бит ASCII). Это сразу же делает поиск ключа в 65536 раз проще, чем он должен быть, даже если не учитывать угадывание пароля.
Наконец, AES имеет специфические уязвимости при атаках на связанные ключи. Атаки на связанные ключи возможны, когда злоумышленник знает некоторые данные, зашифрованные несколькими ключами, и между ними существует некоторая известная (или предполагаемая) связь. Например, если вы зашифровали данные парольным ключом "My AES key sucks" (16 байт, для AES-128) и ключом "MY AES KEY SUCKS", то возможна атака связанными ключами. Наиболее известные в настоящее время атаки не позволяют взломать весь AES таким образом, но со временем они становятся все лучше - буквально на прошлой неделе была опубликована новая атака, которая взламывает 13 раундов (из 14) AES-256 с помощью атаки связанного ключа. Было бы крайне неразумно полагаться на то, что такие атаки не становятся лучше с течением времени.