Chọn khóa mã hóa từ đầu ra Diffie-Hellman

Question

Tôi đã triển khai Diffie–Hellman key exchange bằng Java với một số nhóm lớn từ RFC 3526. Đầu ra của tôi là một mảng khá lớn các byte. Có an toàn khi sử dụng 448 bit đầu tiên (56 byte) đầu ra cho khóa thổi không? Tôi có nên chuyển đổi byte theo bất kỳ cách nào hoặc chọn bất kỳ byte cụ thể nào cho khóa không?

Answer 1

Từ quan điểm lý thuyết, không, không an toàn. Không phải là tôi có thể xác định được một cuộc tấn công thực sự; nhưng đầu ra của trao đổi khóa Diffie-Hellman là phần tử của nhóm bao gồm các yếu tố q và cung cấp bảo mật tối đa sqrt (q). Việc cắt bớt các phần của mã hóa của phần tử đó không giống như một ý tưởng hay ...

Cách "thích hợp" là sử dụng hàm dẫn xuất một chiều. Nói một cách đơn giản, xử lý đầu ra Diffie-Hellman với hàm băm tốt như SHA-256 và sử dụng kết quả băm làm khóa. Thời gian băm sẽ không đáng kể liên quan đến bước Diffie-Hellman. Java đã bao gồm các triển khai tốt của SHA-256 và SHA-512, và nếu bạn sau khi tương thích với các triển khai Java rất cũ (ví dụ Microsoft JVM sắp có với Internet Explorer 5.5) thì bạn có thể sử dụng một thực thi Java độc lập của SHA-2 chẳng hạn như một trong số sphlib. Hoặc có thể reimplement nó từ spec (đó là không khó): FIPS 180-3 (a PDF file).

Nếu bạn cần nhiều hơn 128 bit cho khóa thì điều này có nghĩa là bạn là khách du lịch thời gian từ năm 2050 trở lên; 128 bit (nhiều) quá đủ để bảo vệ bạn trong thời gian này, giả sử rằng bạn sử dụng một lược đồ mã hóa đối xứng thích hợp.

Phát biểu: Blowfish không thực sự được đề xuất nữa. Nó có các khối 64 bit, ngụ ý sự cố khi độ dài dữ liệu được mã hóa đạt đến vài gigabyte, một kích thước không lớn đến mức hiện nay. Bạn nên sử dụng mã hóa khối 128 bit như AES. Ngoài ra, trong bất kỳ hệ thống mã hóa đối xứng nghiêm trọng nào, bạn sẽ cần một kiểm tra tính toàn vẹn được khóa. Điều này có thể được thực hiện với MAC (Mã xác thực thư) chẳng hạn như HMAC, được xây dựng trên một hàm băm (sau đó lại dễ thực hiện và có triển khai Java trong sphlib). Hoặc, thậm chí tốt hơn, sử dụng AES trong chế độ mã hóa/MAC kết hợp sẽ xử lý các chi tiết phức tạp cho bạn (vì sử dụng mật mã khối đúng là không dễ dàng); tra cứu CWC và GCM (cả hai đều không có bằng sáng chế; sau này đã được NIST chấp thuận).

Answer 2

Giải pháp mà bạn đề xuất phụ thuộc vào việc các bit quan trọng nhất của trao đổi Diffie-Hellman là lõi cứng hay không. Có một số kết quả nhỏ được biết rằng cho thấy rằng các bit quan trọng nhất là không thể đoán trước, nhưng tôi không nhận thức được một bài báo đủ mạnh để cho thấy rằng cách tiếp cận của bạn là chính xác.

Tuy nhiên, có một số đề xuất cho một dẫn xuất quan trọng từ các khóa Diffie-Hellman. Ví dụ: một giấy đẹp là NIST SP 800-135. Cho đến nay, đây chỉ là bản nháp và có thể được tìm thấy here. Tuy nhiên, nó xem xét một số tiêu chuẩn hiện có. Tất nhiên, sử dụng một tiêu chuẩn luôn luôn là thích hợp hơn để phát triển nó cho mình.

Mặc dù đề xuất của Thomas Pornin có vẻ hợp lý nhưng dù sao đó là giải pháp đặc biệt. Và để được ở bên an toàn, có lẽ bạn không nên sử dụng nó. Thay vào đó tôi sẽ sử dụng một cái gì đó đã được phân tích (ví dụ: lược đồ dẫn xuất quan trọng được sử dụng trong phiên bản TLS 1.2).