Tham gia Đăng nhập
Điểm:6
A Tea Kettle avatar Crypto

Mã hóa muối dưới dạng hex trước khi băm thực hành xấu?

lá cờ in
A Tea Kettle

Tôi đang đọc một câu hỏi về khóa đối xứng đây và tìm thấy câu trả lời khá thú vị. Nó đề cập:

Đảm bảo chuyển vào các byte thô chứ không phải, ví dụ: chuỗi được mã hóa hex

Ai đó có thể giải thích tại sao điều này là xấu? và cả trong bối cảnh băm mật khẩu, đang chuyển đổi muối thành hex trước khi gửi nó qua HMAC không tốt, và nếu vậy thì tại sao?

2380
0 + 0
Patrick Favre avatar
lá cờ us
Patrick Favre
Chủ đề chính ở đây là khi bạn thực hiện mã hóa (thuộc loại nào, có thể là hex, base64), hãy đảm bảo giải mã trước khi sử dụng và KHÔNG sử dụng biểu diễn byte ASCII của chuỗi mã hóa. Nguyên hàm mật mã thường được tối ưu hóa cho độ dài cụ thể của khóa hoặc muối, vì vậy nếu bạn chuyển độ dài không chính xác, chúng thường bị băm, điều này có thể làm tăng nguy cơ xung đột
1
Hồi đáp
Điểm:17
Marc avatar Crypto
lá cờ in
Marc

Điều này hoàn toàn không nói về muối mà nói về các khóa đối xứng thực tế. Trích dẫn toàn văn:

Hầu hết các môi trường lập trình đều cung cấp một số loại cơ chế "ngẫu nhiên an toàn" (CSPRNG). Bạn có thể sử dụng điều này để thu được một mảng byte có độ dài phù hợp (ví dụ: 32 byte cho AES256), có thể được sử dụng làm khóa. Đảm bảo chuyển vào các byte thô chứ không phải, ví dụ: chuỗi được mã hóa hex.

Điều này có nghĩa là nếu bạn định tạo khóa 32 byte (như được hiển thị trong đoạn văn), hãy đảm bảo đây là 32 byte thô chứ không phải 32 byte của khóa được mã hóa hex.

Lý do cho điều này là đơn giản:

  • 32 byte thô là 256^32 chìa khóa có thể
  • 32 byte dữ liệu thập lục phân là 16^32 chìa khóa có thể

Nếu bạn cần chuyển khóa xung quanh trong biểu diễn thập lục phân, hãy sử dụng toàn bộ đầu ra sẽ dài 64 byte.

Đối với muối, độ mạnh của muối phụ thuộc vào kích thước của nó.Nó không quan trọng nếu nó ở dạng thô hay thập lục phân, đó là số lượng muối có thể có vấn đề.

0 + 0
Maarten Bodewes avatar
lá cờ in
Maarten Bodewes
Các chuỗi cũng có thể khó bị phá hủy hơn, thậm chí chúng có thể bị "nội hóa hóa", tức là được lưu giữ trong suốt vòng đời của máy.
0
Hồi đáp
A Tea Kettle avatar
lá cờ in
A Tea Kettle
Cảm ơn vì lời giải thích tuyệt vời!
0
Hồi đáp
Ben avatar
lá cờ tr
Ben
Tôi không hiểu 32 byte thô khác với 32 byte như thế nào. Dựa trên lời giải thích của bạn, một ký tự hex được lưu trữ trong một byte, nhưng điều đó không bình thường. Cần có hai chữ số thập lục phân trên mỗi byte tương đương với 8 bit và tổng cộng 256 giá trị có thể.
0
Hồi đáp
Marc avatar
lá cờ in
Marc
Hai chữ số thập lục phân có thể đại diện cho một byte. Nhưng nếu bạn có một chuỗi biểu diễn hệ thập lục phân này, thì một byte đơn của chuỗi đã nói sẽ chỉ có một ký tự. Đây là lỗi phổ biến mà mọi người mắc phải: lấy 32 byte đầu tiên của biểu diễn dữ liệu thô ở hệ thập lục phân mà không nhận ra rằng họ đang bỏ đi một nửa số đó.
3
Hồi đáp
Patrick Favre avatar
lá cờ us
Patrick Favre
@marc câu trả lời tuyệt vời, tuy nhiên tôi đồng ý rằng mô tả của 32 byte hex khó hiểu: tại sao không phải là "32 ký tự (cần 32 byte) của dữ liệu thập lục phân là `16^32` khóa có thể"
1
Hồi đáp
Điểm:3
poncho avatar Crypto
lá cờ my
poncho

Ai đó có thể giải thích tại sao điều này là xấu?

Ai nói mã hóa muối trước khi băm là xấu? Khi Tim McLean viết:

Đảm bảo chuyển vào các byte thô chứ không phải, ví dụ: chuỗi được mã hóa hex.

anh ấy đang nói cụ thể về việc tạo khóa cho mật mã đối xứng; anh ấy không nói về việc tạo ra một hình ảnh được băm.

Khi bạn tạo muối cho hàm băm, không có gì sai khi sử dụng mã hóa hex.

0 + 0
lá cờ us
erickson
Thật tệ nếu nó tạo ra sự nhầm lẫn về dữ liệu được băm. Băm mật mã hoạt động trên byte, không phải ký tự, vì vậy văn bản phải được mã hóa thành byte. Tất nhiên, trừ khi bạn đang sử dụng EBCDIC, sẽ không có bất kỳ sự mơ hồ nào khi mã hóa các chữ số thập lục phân. Nhưng nếu một triển khai xem văn bản dưới dạng byte được mã hóa hex và giải mã chúng, trong khi một triển khai khác chỉ xem văn bản và mã hóa nó, thì chúng sẽ không mang lại cùng một hàm băm.
1
Hồi đáp
lá cờ VietNam
Phan Văn Trường
Câu hỏi này là trong các ngôn ngữ khác:

Đă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.