Muối ở đây là tùy chọn nhưng sử dụng nó thêm "sức mạnh". Có phải nó chỉ hữu ích nếu MasterKey yếu?
Nếu khóa Chính không phải là ngẫu nhiên thống nhất, thì bước giải nén trích xuất tính ngẫu nhiên thống nhất từ entropy hiện tại của Tài liệu khóa đầu vào (IKM) ( mật khẩu hoặc khóa của bạn, hoặc ..). Muối bổ sung vào việc củng cố HKDF và hỗ trợ trợ giúp trích xuất độc lập với nguồn để hai IKM khác nhau kết thúc với hai kết quả trích xuất khác nhau. Người ta có thể hưởng lợi từ việc trích xuất độc lập với nguồn ngay cả khi họ có khóa ngẫu nhiên đồng nhất với đủ độ mạnh
Nếu MasterKey của tôi "đủ" mạnh - tôi vẫn cần muối chứ? Nếu không, thế nào là đủ mạnh? Chuỗi hex ngẫu nhiên dài 32 ký tự có đủ không?
Mạnh mẽ không phải là số liệu. Nếu bạn có các bit ngẫu nhiên thống nhất thì bạn không cần bước giải nén của HKDF. Kích thước của các bit phụ thuộc vào nơi bạn sẽ sử dụng; 128-bit cho AES-128, 256-bit AES-256, v.v.
Nếu tôi vẫn nên sử dụng một loại muối thì tất cả B, C và D có thể dùng chung một loại muối hay chúng phải là duy nhất (trong RFC có đề cập đến việc có thể tái sử dụng muối nhưng không hoàn toàn chắc chắn về ý nghĩa của chúng)?
Trên thực tế, khi bạn nhận được Khóa giả ngẫu nhiên (PRK) từ bước Trích xuất, để lấy khóa bạn chỉ cần thay đổi thẻ thông tin.
Tái sử dụng muối có nghĩa là không có quá trình chiết xuất độc lập với nguồn, bạn đang mở rộng cùng một PRK trên mở rộng bước. Bạn có thể muốn sử dụng các PRK khác nhau cho những người dùng khác nhau.
Muối toàn cầu có ổn không?
Bước mở rộng sử dụng HMAC với khóa PRK.
HMAC-Hash(PRK, T(0) | thông tin | 0x01)
HMAC là một PRF và bạn sử dụng muối toàn cầu, sau đó bạn sửa PRF. Vấn đề duy nhất mà tôi có thể thấy là sự va chạm của đầu ra trong thời gian dài. Mặc dù người ta có thể tạo và lưu trữ muối một cách dễ dàng và có được một nhóm PRF thay vì một loại, vậy tại sao không sử dụng các loại muối khác nhau cho mỗi người dùng?
Có hai phần tuyệt vời trong rfc5869
3.1. Muối hay không muối
Tuy nhiên, ngay cả một giá trị muối kém chất lượng hơn (ngắn hơn trong
kích thước hoặc với entropy giới hạn) vẫn có thể tạo ra một giá trị đáng kể
đóng góp cho sự an toàn của tài liệu khóa đầu ra; nhà thiết kế
do đó, các ứng dụng được khuyến khích cung cấp các giá trị muối cho
HKDF nếu ứng dụng có thể nhận được các giá trị đó.
một số ứng dụng thậm chí có thể có sẵn một giá trị muối bí mật để sử dụng; trong trường hợp như vậy, HKDF cung cấp bảo đảm an ninh mạnh mẽ hơn.
3.2 Đầu vào 'thông tin' cho HKDF
... Mục tiêu chính của nó là liên kết tài liệu chính dẫn xuất với thông tin theo ngữ cảnh và ứng dụng cụ thể. Ví dụ: 'thông tin' có thể chứa số giao thức, số nhận dạng thuật toán, danh tính người dùng, v.v. Đặc biệt, nó có thể ngăn việc tạo ra cùng một tài liệu khóa cho các ngữ cảnh khác nhau (khi cùng một tài liệu khóa đầu vào (IKM) được sử dụng trong ngữ cảnh khác nhau).
Trên thực tế, đây không phải là cách chính xác để tạo và phân phối khóa. Bạn nên xem xét các giải pháp mã hóa khóa công khai như RSA-KEM hoặc ECHE trong đó kết quả của cả hai phải được chuyển từ KDF trước khi được sử dụng để mã hóa.
