В чем разница между использованием 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 используется по сравнению с другой альтернативой, которую я упомянул выше?