Điểm:1

Loại sơ đồ mã hóa này có hữu ích trong thực tế không?

lá cờ in

Gần đây, tôi có ý tưởng xây dựng một sơ đồ mã hóa khóa công khai bao gồm năm thuật toán:

  1. Cài đặt($1^k$): tạo tham số công khai $pp$ và một chìa khóa chính $mk$.
  2. KeyGen($pp$): cầm lấy $pp$ làm đầu vào và tạo khóa chung $pk$ và khóa bí mật $sk$.
  3. mã hóa($msg, pk$): cầm lấy $msg, pk$ làm đầu vào, đầu ra bản mã $c$.
  4. giải mã($c, sk$): cầm lấy $c, sk$ như đầu vào, thông báo đầu ra $msg$.
  5. Giải mã toàn cầu($c, mk$): cầm lấy $c, mk$ như đầu vào, thông báo đầu ra $msg$.

Trong các thuật toán trên, khóa chính $mk$ có thể giải mã từng bản mã được tạo bởi thuật toán mã hóa bằng cách sử dụng khác nhau $pk$.

Vì vậy, nếu loại sơ đồ mã hóa này tồn tại, nó có thể có ý nghĩa trong cuộc sống thực không? hoặc nó phù hợp với một số cảnh? những loại cảnh?

jjj avatar
lá cờ cn
jjj
Rõ ràng là bạn sẽ không sử dụng nó nếu bạn không muốn bất kỳ bên thứ 3 nào biết được tin nhắn được mã hóa.Nhưng nếu bạn muốn điều đó, sẽ không cần thuật toán như vậy, bởi vì bạn chỉ có thể mã hóa nó cho cả người nhận và bên thứ ba.
ming alex avatar
lá cờ in
@jjj Giả sử có một công ty có yêu cầu bảo mật là: 1. Tất cả các tin nhắn được truyền trong mạng nội bộ của công ty đều cần được mã hóa, cũng như trong cơ sở dữ liệu. 2. Người kiểm tra nội dung cần kiểm tra tất cả tin nhắn được mã hóa xem có chứa thông tin nhạy cảm, chẳng hạn như bí mật kinh doanh hoặc tin nhắn bất hợp pháp hay không. Bạn có nghĩ rằng chương trình có ý nghĩa cho cảnh này?
fgrieu avatar
lá cờ ng
Một số thiết lập/biến thể của PGP hoạt động như trong câu hỏi. Quá trình mã hóa được định cấu hình để luôn mã hóa bằng khóa chung của công ty (là $pp$ của bạn) ngoài khóa chung của người nhận và khóa riêng của công ty là $mk$ của bạn. Trong những gì bạn mô tả, tham số bảo mật xác định kích thước của $(pk,sk)$ đến từ $pp$ của bạn, tôi không thể nhớ liệu điều đó có được tự động hóa trong các biến thể PGP này hay không và giao diện người dùng có giữ $pp$ với $ không pk$ để tự động mã hóa bằng $pp$.Trong GPG, những điều này là tự nguyện: người dùng chọn kích thước khóa của họ và đặt `encrypt-to pp` trong tệp cấu hình.
poncho avatar
lá cờ my
Trên thực tế, IBE (Mã hóa dựa trên danh tính) đã khá gần với định nghĩa của bạn; sự khác biệt duy nhất là ở bước 2 (trong đó KeyGen cũng phụ thuộc vào khóa chính) và bước 5 (trong đó hoạt động GlobalDecrypt sẽ cần khóa chung)
jjj avatar
lá cờ cn
jjj
@mingalex vâng, nó sẽ hữu ích. Nhưng nó cũng có thể đạt được như tôi đã mô tả. Công ty chỉ có thể yêu cầu nhân viên luôn mã hóa bằng cả hai khóa
ming alex avatar
lá cờ in
@poncho Vâng! chỉ vì tôi đã nghiên cứu về IBE, ý tưởng về IBE đã thôi thúc tôi thiết kế một sơ đồ mã hóa khác đáp ứng một số yêu cầu kỳ lạ... Trong thiết kế của tôi, bộ đôi với IBE gốc cần một bên đáng tin cậy để tạo khóa riêng cho mỗi ID, tôi cố gắng khắc phục thiếu sót để khiến mỗi người dùng tự tạo khóa riêng mà không cần mk.
poncho avatar
lá cờ my
Tôi không rõ việc 'cần khóa chính để tạo khóa bí mật' của IBE lớn đến mức nào là một thiếu sót. Rốt cuộc, với bất kỳ phương pháp nào đáp ứng yêu cầu của bạn, bất kỳ ai có khóa chính đều có thể giải mã bất cứ thứ gì họ muốn, do đó họ nắm giữ các khóa bí mật của mọi người một cách hiệu quả; nơi tính toán thực tế diễn ra quan trọng?

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