Điểm:1

Tạo các cặp khóa bất đối xứng dựa trên các từ khóa sao cho bất kỳ khóa công khai nào dựa trên tập hợp chứa tập hợp con tạo đều hợp lệ

lá cờ tk
Fly

Giả sử chúng ta có rất nhiều người dùng và mỗi người dùng có một danh sách các loại trái cây họ thích - Đó sẽ là các từ khóa. Tôi muốn người dùng của mình có thể mã hóa bất kỳ dữ liệu nào họ lưu trữ (Giả sử, vị trí của cây ăn quả yêu thích của họ), cũng như giải mã dữ liệu đó: Vì vậy, tôi muốn có thể tạo cặp khóa công khai/riêng tư dựa trên dữ liệu của họ. danh sách từ khóa cụ thể.

Điều này cũng ngụ ý rằng bất kỳ người dùng nào có cùng danh sách từ khóa đều có thể truy cập dữ liệu đã được mã hóa trước đó. Tuy nhiên, tôi muốn tiến thêm một bước nữa: Tôi muốn tất cả người dùng có danh sách từ khóa chứa danh sách từ khóa được sử dụng để mã hóa dữ liệu dưới dạng tập hợp con, cũng có quyền truy cập vào dữ liệu được mã hóa đó.

Trong ví dụ của tôi, điều này có nghĩa như sau: Tất cả những người thích loại trái cây giống hoặc hơn người khác sẽ có thể giải mã vị trí cây ăn quả của người đó.

Về bản chất, tôi muốn các cặp khóa của mình gói gọn lẫn nhau theo cách nào đó: Khóa chung được tạo bởi một danh sách từ khóa nhất định phải khớp với tất cả các khóa riêng được tạo bởi bất kỳ tập hợp con nào của danh sách từ khóa đó.

Thật không may, tôi không phải là chuyên gia trong lĩnh vực mật mã, vì vậy tôi đã tự hỏi: Có ai biết cách tôi có thể đạt được việc tạo cặp khóa với các thuộc tính được mô tả ở trên không?

Cảm ơn!

knaccc avatar
lá cờ es
Máy chủ phải không có khả năng hiển thị loại trái cây nào mà mọi người thích? Hay máy chủ được phép biết loại trái cây mà mỗi người thích, nhưng không phải là dữ liệu được mã hóa cho danh sách đó? Và có điều gì ngăn cản ai đó chỉ thêm tất cả các loại trái cây có thể để họ có thể truy cập vào mọi thứ không? Là danh sách của tất cả các loại trái cây có thể là một bí mật? Mọi người có thể thích bất kỳ loại trái cây nào, hay họ phải được phép "tiếp cận" để thích một loại trái cây? Và nếu máy chủ chỉ tạo một tài khoản người dùng thích tất cả các loại trái cây có thể để xem tất cả dữ liệu thì sao?
lá cờ tk
Fly
@knaccc Máy chủ biết (và trên thực tế, thậm chí lưu trữ nó không được mã hóa) chính xác ai thích loại trái cây nào. Phần còn lại của các câu hỏi của bạn chắc chắn có liên quan đến các giai đoạn sử dụng thực tế của một hệ thống như vậy, nhưng tôi nghĩ không nên ảnh hưởng đến chính thuật toán tạo khóa; nhưng trong trường hợp của tôi, chỉ một người thích một loại trái cây cụ thể mới có thể cho người khác biết rằng loại trái cây này tồn tại, trong trường hợp đó họ mới được phép thích nó. Tài khoản người dùng thích tất cả trái cây về cơ bản là tài khoản chính, người sau đó thực sự có quyền truy cập vào tất cả dữ liệu.
knaccc avatar
lá cờ es
Có vẻ như máy chủ sẽ có quyền truy cập vào danh sách tất cả các loại trái cây có thể có, do đó có thể dễ dàng giải mã và xem bất kỳ thông tin nào mà bất kỳ người dùng nào đã lưu trữ. Vì vậy, mục đích của việc bất kỳ ai có một cặp khóa và thực hiện bất kỳ mã hóa nào là gì, nếu máy chủ vẫn có thể nhìn thấy mọi thứ?
lá cờ tk
Fly
@knaccc Chà, rò rỉ cơ sở dữ liệu sẽ không mang lại bất kỳ dữ liệu nào do mã hóa.
knaccc avatar
lá cờ es
Nếu máy chủ có thể nhìn thấy tất cả dữ liệu, thì một sự thỏa hiệp máy chủ sẽ làm rò rỉ tất cả dữ liệu. Bạn có thể mã hóa toàn bộ cơ sở dữ liệu đang lưu trữ bằng mã hóa đối xứng thông thường và điều đó sẽ tương đương với những gì bạn đang đề xuất. Cách duy nhất mà một sơ đồ mã hóa phức tạp như sơ đồ bạn đang đề xuất sẽ có ý nghĩa là nếu nó được thực hiện sao cho quản trị viên máy chủ không thể nhìn thấy bất kỳ dữ liệu nào, bởi vì chỉ người dùng mới có khóa riêng để giải mã dữ liệu.
lá cờ cn
Về cơ bản, thứ bạn mô tả được gọi là [mã hóa dựa trên thuộc tính](https://en.wikipedia.org/wiki/Attribute-based_encryption).
Điểm:1
lá cờ es

Một loại trái cây sẽ được tạo bởi người dùng và sẽ gán cho nó một khóa bí mật $x$. Người dùng sẽ thông báo cho máy chủ về sự tồn tại của loại trái cây này, chỉ xác định nó bằng nhãn và giữ $x$ bí mật.

Tất cả người dùng có cặp khóa EC cá nhân của riêng họ, trong đó khóa bí mật cá nhân của họ không được tiết lộ cho máy chủ. Khi ai đó được mời thích một loại trái cây, lời mời sẽ mã hóa khóa bí mật của loại trái cây đó $x$ với khóa công khai cá nhân của người được mời để liên lạc với họ.

Khi người dùng muốn mã hóa thông tin chỉ hiển thị cho người dùng biết khóa bí mật cho một tập hợp các loại trái cây có khóa bí mật là $\{x_1 , x_2 , x_3\}$, người dùng chỉ cần mã hóa nó bằng mã hóa AEAD đối xứng với khóa bí mật $H(x_1 | x_2 | x_3)$, ở đâu $H$ là một cấu trúc hàm băm bảo mật bằng mật mã miễn nhiễm với các cuộc tấn công mở rộng độ dài. Danh sách các khóa bí mật của trái cây phải luôn được nối theo thứ tự từ điển của chúng.Người dùng sẽ gắn nhãn dữ liệu được mã hóa để những người khác biết họ sẽ cần tập hợp con khóa nào để giải mã dữ liệu đó. Người dùng có thể muốn ký dữ liệu mà họ đã mã hóa bằng khóa công khai cá nhân của họ.

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