Почему мне нужно использовать класс Rfc2898DeriveBytes (in.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' теперь можно использовать в направлении настройка интернет .Ключ или. IV свойства
о классе симметричного алгоритма шифрования.
ie.
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 бит). Это сразу же делает keysearch 65536 раз проще, чем должно быть, даже игнорируя угадывание пароля.
наконец, AES имеет определенные уязвимости с соответствующими ключевыми атаками. Связанные ключевые атаки возможны, когда злоумышленник знает некоторые данные, зашифрованные несколькими ключами, и существует некоторая известная (или предполагаемая) связь между ними. Например, если вы зашифровали данные как с помощью пароля-ключа "My AES key sucks" (16 байт, для AES-128), так и с помощью "MY AES Ключ сосет", может быть возможна связанная ключевая атака. В настоящее время наиболее известные атаки фактически не позволяют нарушать полный AES таким образом, но они постепенно улучшаются с течением времени - только на прошлой неделе была опубликована новая атака, которая разбивает 13 раундов (из 14 всего) AES-256 с использованием связанной ключевой атаки. Было бы крайне неразумно полагаться на то, что такие атаки со временем не станут лучше.
Comments