Ответ 1
В этом blogpost говорится о различиях между ними: http://blogs.msdn.com/shawnfa/archive/2004/04/14/generating-a-key-from-a-password.aspx
Я работаю над функцией шифрования, основанной на классах, унаследованных от SymmetricAlgorithm, таких как TripleDes, DES и т.д.
В принципе существует два варианта генерации согласованного ключа и IV для моего класса алгоритма PasswordDeriveBytes
и Rfc2898DeriveBytes
, оба наследуются от абстрактного класса DeriveBytes.
Метод PasswordDeriveBytes.GetBytes()
помечен как устаревший в платформе .NET, тогда как рекомендуется Rfc2898DeriveBytes.GetBytes(), так как он соответствует стандарту PBKDF2. Однако, основываясь на моем тестировании, вызов того же метода GetBytes()
в классе Rfc2898DeriveBytes почти в 15 раз медленнее, чем в классе PasswordDeriveBytes
, что приводит к неожиданному использованию ЦП (всегда выше 50%).
Вот некоторые данные тестирования:
На основе тестирования плохая производительность Rfc2898DeriveBytes
неприемлема в производственной среде.
Кто-нибудь заметил эту проблему раньше? Любое решение, я все еще могу использовать стандартный, не нажимая на производительность? Любой риск использования устаревшего метода (может быть удален в будущей версии)?
Спасибо, ребята!
Edit:
Вероятно, я нашел, где проблема... Номер подсчета итераций по умолчанию для PasswordDeriveBytes
равен 100, а для Rfc2898DeriveBytes
- 1000. После того как я изменил их на тот же номер, что и 1000, выполнение Rfc2898DeriveBytes
двойное время.
В этом blogpost говорится о различиях между ними: http://blogs.msdn.com/shawnfa/archive/2004/04/14/generating-a-key-from-a-password.aspx
Это не одно и то же.
Rfc2898DeriveBytes - это реализация PBKDF2. PasswordDeriveBytes - это реализация PBKDF1. PBKDF2 генерирует другой выход, используя другой метод, и гораздо большее количество раундов, чем PBKDF1.
Функции хеширования паролей, такие как эти, которые используются для деривации ключей, должны быть медленными. То, что точка - это делает их гораздо труднее взломать.
Две функции несовместимы, и PasswordDeriveBytes не так безопасен.
Я думаю, что вам не хватает точки дериваблей. Предполагается, что он медленный. Он намеренно использует медленный алгоритм, который не может быть ускорен с помощью умного трюка. Типичный параметр "число итераций" должен быть в диапазоне 2 ^ 16-2 ^ 20 и вводить задержку 0,1-0,5 секунды между пользователем, вводящим пароль, и генерируется ключ. Цель состоит в том, чтобы защитить от слабых паролей, выбранных "ленивыми неосведомленными пользователями", и замедлить поиск грубой силы.