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