it-swarm-vi.com

Mã hóa - tôi nên sử dụng RSA hay AES?

Mô hình của tôi là một trong đó tôi có một số khách hàng muốn nói chuyện với một số (nhưng không phải tất cả) các khách hàng khác.

Tất cả các tin nhắn sẽ được gửi qua một máy chủ.

Chỉ có hai khách hàng giao tiếp với nhau mới có thể biết tin nhắn. Vì vậy, máy chủ VÀ các máy khách khác sẽ không thể tìm ra thông điệp nào được gửi.

Giao tiếp giữa hai khách hàng có thể bắt đầu và kết thúc nhiều lần trong ngày.

Tin nhắn sẽ là bản rõ với độ dài không giới hạn, nhưng có thể ít hơn nhiều, hãy nghĩ SMS tin nhắn kiểu.

Với những trường hợp này, tôi nên mã hóa các tin nhắn như thế nào? Tôi không ngại viết thêm mã nếu nó dẫn đến tốc độ hoặc hiệu quả tốt hơn.

Tôi biết những điều cơ bản về cách thức hoạt động của RSA và AES nhưng tôi không thể tìm ra cái gì là tốt nhất.

Khi bạn tạo cặp khóa công khai/riêng cho RSA, có trường hợp nào bạn cần tạo một cặp mới không? Hoặc một khách hàng có thể có một khóa chung và đưa cùng một khóa cho bất kỳ ai muốn nói chuyện với anh ta và chỉ anh ta mới có thể đọc tin nhắn, nhưng họ lưu trữ khóa chung cho tất cả các tin nhắn trong tương lai?

Hoặc tôi nên có một khóa AES đối xứng riêng cho cặp khách hàng và chỉ cần chia sẻ rằng khi liên hệ được bắt đầu lần đầu và sử dụng nó mãi mãi. Một lần nữa, có bất kỳ trường hợp nào mà điều này sẽ cần phải được tạo lại?

Làm thế nào tôi có thể lưu trữ (các) khóa để chúng tồn tại nếu máy khách gặp sự cố/tắt/khởi động lại?

39
Cheetah

Không, trừ khi cả hai. Bạn đang hỏi sai câu hỏi . Bạn không nên nghĩ về một thuật toán mã hóa ở giai đoạn này, mà là về một giao thức mã hóa.

Các giao thức mật mã khó thiết kế và là nguồn thường xuyên xảy ra lỗi bảo mật. Bạn không hiểu đầy đủ về mật mã khóa công khai, vì vậy bạn chưa sẵn sàng sử dụng nó trong giao thức mật mã của riêng bạn.

Ở cấp độ cao, mô hình của bạn có thể tuân theo mật mã khóa công khai (ví dụ: RSA). Hãy để mọi khách hàng có khóa riêng của mình và xuất bản khóa chung của nó cho khách hàng khác. Khóa riêng của khách hàng không thay đổi theo thời gian, trừ khi khách hàng bị xâm phạm. Mật mã đối xứng (ví dụ: AES) sẽ không mở rộng tốt ở đây vì mỗi cặp của khách hàng sẽ cần phải có khóa bí mật riêng.

Sử dụng phần mềm hiện có bất cứ khi nào có thể. Việc thực hiện các giao thức mật mã gần như khó khăn như thiết kế chúng. Đối với một mô hình mà khách hàng thỉnh thoảng gửi tin nhắn cho nhau, kiểu email, một công cụ sẽ hoạt động tốt là GnuPG . (Đối với liên lạc hai chiều, hãy sử dụng SSL/TLS .)

Vì vậy: đối với hoạt động hàng ngày, để gửi tin nhắn, hãy gọi gpg, mã hóa bằng khóa chung của người nhận và trong khi bạn ký tên với khóa riêng của người gửi. Khi nhận được tin nhắn, hãy kiểm tra chữ ký dựa vào khóa chung của người gửi và giải mã bằng khóa riêng của người nhận. Nói cách khác, gửi với gpg --sign --encrypt -r NAME_OF_RECIPIENT và nhận với gpg --verify theo dõi bởi gpg --decrypt.

Vấn đề còn lại là phân phối khóa. Sau khi một khách hàng đã tạo cặp khóa của mình, nó cần thông báo cho các khách hàng khác về nó và phân phối nó mà không cho phép khóa công khai bị chặn và thay thế trong quá trình bởi kẻ tấn công. Làm thế nào để làm điều này phụ thuộc rất nhiều vào kịch bản chính xác của bạn. Đừng bỏ bê bảo mật của phần này.

Nếu và chỉ khi, việc gọi GnuPG chứng tỏ là quá chậm, thì hãy cân nhắc sử dụng một giao thức tương tự có trọng lượng nhẹ hơn, có thể được thực hiện tại nhà của một giao thức tương tự (đi từ phạm vi email đến SMS trên phạm vi hoạt động). Dưới mui xe, GnuPG tạo khóa đối xứng cho mỗi tin nhắn, bởi vì mật mã khóa công khai rất tốn kém cho các tin nhắn lớn, thuật toán khóa công khai chỉ được sử dụng để mã hóa khóa đối xứng và ký tên vào bản tóm tắt của tệp. Nên theo mô hình này. Sử dụng AES để mã hóa đối xứng, SHA-256 làm thuật toán tiêu hóa và RSA làm thuật toán khóa công khai là một lựa chọn tốt.

Như đã nói trong In silico, RSA và AES phục vụ hai mục đích khác nhau. AES là một thuật toán nhanh, phù hợp để mã hóa toàn bộ cuộc hội thoại. Nhưng nó có một vấn đề: làm thế nào để quyết định sử dụng khóa nào giữa hai bên mà không có bên kia biết?

RSA có thể là giải pháp cho vấn đề này. Nếu Mọi người tham gia đều có khóa RSA công khai của mọi người tham gia khác, bất kỳ ai cũng có thể bắt đầu liên lạc được mã hóa với bất kỳ ai khác (bằng cách sử dụng khóa chung của người tham gia khác) và quyết định sử dụng khóa AES bí mật. Khi khóa AES được quyết định, phần còn lại của cuộc trò chuyện có thể được mã hóa bằng AES. Để chứng minh rằng với người tham gia B rằng đó thực sự là A muốn nói chuyện với anh ta, có thể sử dụng chữ ký số.

Những gì tôi mô tả là, grosso modo, những gì bắt tay SSL làm khi trình duyệt kết nối với máy chủ web hỗ trợ SSL.

19
JB Nizet

Đừng hiểu sai ý này nhưng ...

Tôi biết những điều cơ bản về cách thức hoạt động của RSA và AES nhưng tôi không thể tìm ra cái gì là tốt nhất.

Nếu bạn chỉ biết những điều cơ bản, bạn có thể không phải là người phù hợp để giải quyết vấn đề này (chưa). Bảo mật là một trong những lĩnh vực mà bạn phải là rất cụ thể và cẩn thận nếu không bạn sẽ vô hiệu hóa toàn bộ thiết lập bảo mật của mình.

Ngoài ra, tôi không tin rằng chúng tôi có đủ thông tin để cung cấp cho bạn câu trả lời thích hợp. Các hợp đồng kinh doanh về kỳ vọng bảo mật sẽ phải được biết trước.

Trong hầu hết các trường hợp, các khóa không bao giờ rời khỏi máy mà chúng được tạo vì lý do bảo mật, vì vậy nếu bạn có ý định "chia sẻ" thông tin thì giải pháp khóa chung thường là lựa chọn đúng từ quan điểm bảo mật thuần túy. Ngoại lệ cho điều này là nếu bạn có thể chia sẻ khóa đối xứng một cách an toàn, chẳng hạn như gửi khóa cho người đó trên phương tiện vật lý.

6
Andrew White

Về cơ bản, việc sử dụng mã hóa khóa chung (như RSA) đắt hơn nhiều so với sử dụng mã hóa khóa đối xứng (như AES) và khi có nhiều thông điệp truyền từ người này sang người khác, tốt hơn là sử dụng đối xứng Chìa khóa.

Bây giờ, việc tạo và trao đổi khóa đối xứng có thể được thực hiện bằng mã hóa khóa chung.

Ví dụ:

Mỗi máy khách có một cặp khóa riêng-công khai và khóa chung được lưu trữ trên máy chủ. Khi hai khách hàng bắt đầu phiên giao tiếp, mỗi người sẽ lấy khóa chung của người kia từ máy chủ và gửi một số được mã hóa cho người kia. Sau đó, mỗi bên băm hai số đó và sử dụng kết quả làm chìa khóa để mã hóa/giải mã dữ liệu kể từ bây giờ.

3
MByD

Nếu bạn sử dụng kiểu CÔNG KHAI/RIÊNG TƯ (RSA với đủ bit :)), bạn có thể thiết lập loại giao tiếp an toàn mà bạn mô tả theo cách này:

  1. Alice viết một tin nhắn
  2. Alice mã hóa nó bằng cách sử dụng Alice 's PRIVATE key
  3. Alice mã hóa lại lần nữa bằng cách sử dụng Bob 's CÔNG KHAI
  4. Alice gửi kết quả cho Bob.

Sau đó:

  1. Bob nhận được tin nhắn (được cho là) ​​từ Alice
  2. Bob giải mã nó bằng cách sử dụng Bob 's PRIVATE key
  3. Bob giải mã lại lần nữa bằng cách sử dụng Alice 's CÔNG KHAI key
  4. Nếu mọi việc suôn sẻ, Bob đọc tin nhắn.

Ghi chú:

  • Bob là người duy nhất có thể đọc tin nhắn này.
  • Bob biết mà không nghi ngờ gì rằng nó đến từ Alice.

Nhận cả hai thuộc tính đó với AES là một chút khó khăn hơn.

2
Jesse Chisholm