Điểm:0

Trao đổi khóa có được xác thực và bảo mật không?

lá cờ in

Tôi đã tạo một chương trình nhắn tin riêng và muốn kiểm tra xem có điều gì ngu ngốc trong việc sử dụng mật mã của tôi không. Tôi là một người nghiệp dư và không có gì là để sản xuất. Tôi cảm ơn bạn trước.

Việc trao đổi tin nhắn được mã hóa nối đầu với AES-OCB. Khóa phiên được trao đổi như sau:

Lúc đầu, khóa riêng được tải và khóa chung được tạo. Máy chủ gửi khóa công khai của nó cho máy khách. Máy khách xác minh khóa công khai của máy chủ bằng tệp know_host. Trong tệp này, các địa chỉ máy chủ được lưu trữ ở dạng băm (sha256) với khóa công khai của chúng (sha256). Máy khách kiểm tra xem khóa chung đã nhận có đúng không, nếu không, dấu vân tay sha256 của khóa chung sẽ được hiển thị để người dùng xác minh.

Máy khách tạo khóa phiên 128 bit và mã hóa nó bằng khóa chung của máy chủ. Máy khách gửi đến máy chủ: khóa phiên được mã hóa, khóa công khai của nó, chữ ký RSASSA-PSS (sha256) của khóa phiên.

Máy chủ xác minh danh tính của máy khách bằng tệp know_host của chính nó. Nó giải mã khóa phiên. Nó xác minh chữ ký của khóa phiên bằng khóa chung của khách hàng.

Cả hai bên được xác thực và có khóa phiên, giao tiếp bình thường bắt đầu.

Điểm:1
lá cờ kr
  1. Đề án của bạn có không có bí mật về phía trước. Nếu một ngày nào đó kẻ tấn công lấy được khóa riêng của máy chủ, tất cả các phiên trước đó có thể được giải mã: Khóa phiên có thể được giải mã và do đó, các phiên tương ứng có thể được giải mã. Xem chi tiết đây.

  2. kế hoạch của bạn là dễ bị tấn công lại. Nếu kẻ tấn công chặn lưu lượng và biết ý nghĩa của một phần cụ thể của dữ liệu được mã hóa, thì kẻ tấn công có thể gửi lại những dữ liệu này. Nếu nó được thực hiện trong cùng một phiên, thì cùng một khóa mã hóa vẫn được sử dụng và sẽ không thể phát hiện liệu tin nhắn có thực sự được gửi bởi phía bên kia hay nó được gửi bởi kẻ tấn công. Tùy thuộc vào ngữ nghĩa của thông điệp, nó có thể nguy hiểm. Xem chi tiết đây.

SAI Peregrinus avatar
lá cờ si
Ngoài ra, phương thức mà máy khách sử dụng để mã hóa khóa phiên không được chỉ định. Nếu đó là RSAES-OAEP thì không sao, nhưng bất kỳ thứ gì khác sẽ có một số cảnh báo hoặc hoàn toàn không an toàn. Và tốt hơn hết là sử dụng RSA-KEM hoặc ECDH để tạo bí mật dùng chung thay vì mã hóa và gửi bí mật.
lá cờ kr
@SAIPeregrinus: Chắc chắn rồi. Và đường hầm SSH hoặc TLS sẽ tốt hơn giao thức tự tạo.
SAI Peregrinus avatar
lá cờ si
Đã đồng ý. Hoặc ít nhất là một giao thức Tiếng ồn, nếu SSH hoặc TLS (hoặc Wireguard) không hoạt động vì bất kỳ lý do gì.
lá cờ in
Để mã hóa khóa phiên, tôi sử dụng RSAES-OAEP. Nếu tôi sử dụng ECDH để trao đổi khóa phiên, vấn đề "không bảo mật về phía trước" có được giải quyết không?
lá cờ kr
@Laurent57: Không hẳn. Nó phải là ECDHE, ECDH phù du. Sau đó, bạn sẽ có bí mật về phía trước.
lá cờ in
Cảm ơn bạn đã trả lời hữu ích của bạn, tôi đánh giá cao thông tin phản hồi của bạn.

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