Tại sao tôi cần sử dụng lớp Rfc2898DeriveBytes (trong .NET) thay vì trực tiếp sử dụng mật khẩu làm khóa hoặc IV?

Sự khác biệt giữa sử dụng Rfc2898DeriveBytes và chỉ sử dụng là Encoding.ASCII.GetBytes(string object);gì?

Tôi đã thành công tương đối với một trong hai cách tiếp cận, cách tiếp cận đầu tiên là cách tiếp cận dài hơi hơn trong đó cách tiếp cận sau là đơn giản và đi vào trọng tâm. Cả hai dường như cho phép bạn làm điều tương tự cuối cùng nhưng tôi đang đấu tranh để thấy điểm trong việc sử dụng cái trước hơn cái sau.

Khái niệm cơ bản mà tôi có thể nắm được là bạn có thể chuyển đổi mật khẩu chuỗi thành mảng byte để sử dụng cho lớp mã hóa đối xứng, ví dụ AesManaged. Qua lớp RFC nhưng bạn có thể sử dụng các giá trị muối và mật khẩu khi tạo đối tượng rfc của mình. Tôi cho rằng nó an toàn hơn nhưng tốt nhất đó vẫn chỉ là một phỏng đoán vô học! Ngoài ra, nó cho phép bạn trả về các mảng byte có kích thước nhất định, đại loại như vậy.

Dưới đây là một số ví dụ để bạn thấy tôi đến từ đâu:

byte[] myPassinBytes = Encoding.ASCII.GetBytes("some password");

hoặc là

string password = "P@%5w0r]>";
byte[] saltArray = Encoding.ASCII.GetBytes("this is my salt");
Rfc2898DeriveBytes rfcKey = new Rfc2898DeriveBytes(password, saltArray);

Đối tượng 'rfcKey' bây giờ có thể được sử dụng để thiết lập các thuộc tính .Key hoặc .IV trên một lớp thuật toán mã hóa đối xứng.

I E.

RijndaelManaged rj = new RijndaelManaged ();
rj.Key = rfcKey.Getbytes(rj.KeySize / 8); 
rj.IV = rfcKey.Getbytes(rj.Blocksize / 8);

'rj' sẽ sẵn sàng hoạt động!

Phần khó hiểu ... vì vậy thay vì sử dụng đối tượng 'rfcKey', tôi có thể không sử dụng mảng 'myPassInBytes' để giúp thiết lập đối tượng 'rj' của mình không?

Tôi đã thử làm điều này trong VS2008 và câu trả lời ngay lập tức là KHÔNG. Nhưng các bạn đã có câu trả lời tốt hơn về lý do tại sao lớp RFC được sử dụng thay thế cho các phương thức thay thế khác mà tôi đã đề cập ở trên chưa?

Bạn thực sự không muốn sử dụng trực tiếp mật khẩu người dùng làm khóa mật mã, đặc biệt là với AES.

Rfc2898DeriveBytes là một triển khai của PBKDF2. Những gì nó làm là băm nhiều lần mật khẩu người dùng cùng với muối. Điều này có nhiều lợi ích:

Thứ nhất, bạn có thể sử dụng mật khẩu có kích thước tùy ý - AES chỉ hỗ trợ kích thước khóa cụ thể.

Thứ hai, việc thêm muối có nghĩa là bạn có thể sử dụng cùng một cụm mật khẩu để tạo ra nhiều khóa khác nhau (giả sử muối không phải là một hằng số, như trong ví dụ của bạn). Điều này rất quan trọng đối với việc tách khóa; sử dụng lại các khóa trong các ngữ cảnh khác nhau là một trong những cách phổ biến nhất mà hệ thống mật mã bị phá vỡ.

Nhiều lần lặp lại (1000 theo mặc định) làm chậm các cuộc tấn công đoán mật khẩu. Xem xét ai đó đang cố gắng đoán khóa AES của bạn. Nếu bạn chỉ sử dụng mật khẩu, điều này sẽ đơn giản - chỉ cần thử từng mật khẩu có thể làm khóa. Mặt khác, với PBKDF2, trước tiên kẻ tấn công phải thực hiện 1000 lần lặp băm cho mỗi lần đoán mật khẩu. Vì vậy, mặc dù nó chỉ làm chậm người dùng một chút, nhưng nó có tác động không cân xứng đối với kẻ tấn công. (Trên thực tế, việc sử dụng số lần lặp cao hơn rất nhiều; 10000 thường được khuyến khích).

Nó cũng có nghĩa là khóa đầu ra cuối cùng được phân phối đồng nhất. Ví dụ: nếu bạn sử dụng mật khẩu, thông thường 16 trong số 128 bit của khóa sẽ là 0 (bit ASCII cao). Điều đó ngay lập tức làm cho việc tìm kiếm keysearch dễ dàng hơn 65536 lần so với dự kiến, thậm chí bỏ qua việc đoán mật khẩu.

Cuối cùng, AES có các lỗ hổng cụ thể với các cuộc tấn công chính liên quan. Các cuộc tấn công khóa liên quan có thể xảy ra khi kẻ tấn công biết một số dữ liệu được mã hóa bằng một số khóa và có một số mối quan hệ đã biết (hoặc đoán) giữa chúng. Ví dụ: nếu bạn đã mã hóa dữ liệu bằng cả khóa mật khẩu của "My AES key" (16 byte, đối với AES-128) và với "MY AES KEY SUCKS", một cuộc tấn công khóa liên quan có thể xảy ra. Các cuộc tấn công được biết đến nhiều nhất hiện nay không thực sự cho phép phá vỡ toàn bộ AES theo cách này, nhưng chúng đang dần trở nên tốt hơn theo thời gian - chỉ tuần trước, một cuộc tấn công mới đã được công bố phá vỡ 13 vòng (trong tổng số 14) của AES-256 bằng cách sử dụng một cuộc tấn công chính liên quan. Sẽ thực sự thiếu khôn ngoan nếu dựa vào những cuộc tấn công không tốt lên theo thời gian.