Điểm:1

Tạo và mã hóa khóa HMAC

lá cờ ng

Tôi có đoạn mã .NET này dựa trên một Mẫu của Microsoft về cách tạo khóa và ký bằng HMACSH256.

Nhưng tôi đã thay đổi cách tạo khóa một chút và cũng quyết định sử dụng Base64 để truyền khóa dưới dạng chuỗi:

Tạo khóa:

byte[] secretkey = new Byte[64];

sử dụng (RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider())
{
    rng.GetBytes(khóa bí mật);
    sử dụng (SHA512 mySHA256 = SHA512.Create())
    {
          var hashKey = mySHA256.ComputeHash(khóa bí mật);
          var encodedKey = Convert.ToBase64String(hashedKey);
          trả lại khóa mã hóa;
    }
}

Vì vậy, bên cạnh việc tạo các byte ngẫu nhiên, tôi cũng quyết định băm khóa bằng SHA512. Và sau đó mã hóa Base64 để có được biểu diễn chuỗi cuối cùng, sẽ chỉ được sử dụng trong truyền tải, vì trước khi sử dụng, người nhận tin nhắn sẽ giải mã trở lại thông báo SHA512.

Có vấn đề gì với cách tôi đang làm không? Trừ khi tôi nhầm, tất cả việc băm sẽ làm là tạo ra nhiều tính ngẫu nhiên hơn, vì khóa sẽ duy trì ở độ dài 64 byte. Nó có đáng không?

Ngoài ra, có vấn đề gì với việc vận chuyển khóa dưới dạng chuỗi Base64 không?

Cảm ơn, và tôi hy vọng ai đó có thể cung cấp một số thông tin phản hồi về điều này. Có một cái tốt!

Điểm:1
lá cờ cn

tất cả việc băm sẽ làm là giới thiệu nhiều tính ngẫu nhiên hơn

Không. Bạn không thể giới thiệu tính ngẫu nhiên với một quy trình xác định. Bạn chỉ có thể giới thiệu tính ngẫu nhiên với một nguồn dữ liệu ngẫu nhiên thực tế.

Bạn có thể sử dụng hàm băm như một thành phần của một trình tạo giả ngẫu nhiên và một trình tạo giả ngẫu nhiên (an toàn về mật mã!) đủ tốt cho mật mã khi cần tính ngẫu nhiên, nhưng một thành phần quan trọng khác của trình tạo giả ngẫu nhiên là một bí mật. Bí mật đó là trạng thái của trình tạo ngẫu nhiên, bắt nguồn từ hạt giống ngẫu nhiên: trình tạo giả ngẫu nhiên không tạo ra tính ngẫu nhiên, nó chỉ “nhân lên” theo nghĩa là nó có thể biến một lượng nhỏ dữ liệu ngẫu nhiên thành một lượng lớn dữ liệu ngẫu nhiên. lượng dữ liệu ngẫu nhiên.

Băm một chuỗi ngẫu nhiên chỉ làm giảm tính ngẫu nhiên của nó: về mặt lý thuyết, có thể hai chuỗi đầu vào có cùng một hàm băm (bạn sẽ không thực sự tìm thấy các chuỗi như vậy và chúng tôi không chắc chúng tồn tại, nhưng rất có thể là có). Tính ngẫu nhiên chỉ giảm đi một lượng nhỏ, vì vậy đây không phải là một lỗ hổng thực sự trong mã của bạn, nhưng nó là một sự phức tạp không cần thiết và phản tác dụng.

Cách để tối đa hóa tính ngẫu nhiên là lấy đầu ra từ một trình tạo ngẫu nhiên. Cuộc gọi rng.GetBytes(khóa bí mật) và dừng lại ở đó.

Chuyển đổi khóa thành Base64 để vận chuyển và sau đó quay lại nhị phân để sử dụng không ảnh hưởng đến mật mã. Nó chỉ là một mã hóa. Hãy giải mã nó: sử dụng Base64 làm khóa có thể làm giảm tính bảo mật vì mỗi byte chỉ có thể có 1/4 giá trị có thể. (Cách HMAC sử dụng khóa của nó, việc bạn sử dụng cơ sở64(random_bytes(64)) hoặc Random_bytes(64) như một chìa khóa; nhưng điều này sẽ quan trọng, ví dụ, đối với khóa AES, thậm chí không có độ dài chấp nhận được.)

danutz_plusplus avatar
lá cờ ng
Cảm ơn cho bài chiếu sáng. Vâng, bây giờ khi bạn đề cập đến nó, rõ ràng là vì bản tóm tắt nằm trong một không gian giảm giá trị nên về mặt lý thuyết nó sẽ bị giảm. Bây giờ tôi nghĩ về nó, tôi đã có ý tưởng từ một hệ thống khác nơi tôi thấy rằng họ đã sử dụng mật khẩu được tạo ngẫu nhiên (không được sử dụng bởi người thực) và họ đã băm các giá trị trước khi lưu trữ chúng. Nhưng bây giờ nghĩ lại, tôi nghĩ đó là vì mục đích không cho phép thiết kế ngược các giá trị của chúng. Như bạn thường làm với mật khẩu.
danutz_plusplus avatar
lá cờ ng
Về mã hóa, vâng, tôi đã nghĩ rất nhiều rằng tôi phải giải mã nó trước khi sử dụng. May mắn thay, API đủ thông minh để thậm chí không chấp nhận một chuỗi. Nó chỉ chấp nhận một byte [].
danutz_plusplus avatar
lá cờ ng
Ngoài ra, xin vui lòng bỏ qua sự lặp lại của "bây giờ tôi nghĩ về nó". Có vẻ như tôi đã không suy nghĩ chính xác về câu trả lời và tiếp tục chỉnh sửa nó cho đến khi nó gần như mất hết ý nghĩa. :D Và bây giờ tôi không thể chỉnh sửa nó trong 5 phút :D

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.