Đầu tiên giải quyết phần bổ sung: Khi bạn giải quyết loại vấn đề này, bạn thường kết thúc với một số loại giao thức để chứng minh rằng người dùng diễn đàn được xác nhận là một phần của nhóm người dùng diễn đàn hiện tại. Khi nhóm người dùng diễn đàn hiện tại thay đổi, bạn có thể chạy lại giao thức này để xác minh rằng người dùng được đề cập vẫn được ủy quyền.Điều này thậm chí còn hoạt động tốt hơn nếu bạn có một số loại định danh giả ngẫu nhiên xác định cho mỗi người dùng diễn đàn.
Đối với phần bằng chứng thực tế, tôi thấy có hai tùy chọn: Sử dụng bằng chứng không kiến thức với hàm băm và bằng chứng thành viên nhóm hoặc sử dụng giao thức tính toán hai bên với PRF và vị từ thành viên nhóm. Nếu không có phần bút danh, đây sẽ là trường hợp tiêu chuẩn cho chữ ký vòng hoặc chữ ký nhóm chứng minh rằng bạn có thể tạo chữ ký hợp lệ theo một khóa chung từ một nhóm. Thay vào đó, nếu bạn có thể thuyết phục hoạt động của diễn đàn cộng tác, đó sẽ là việc sử dụng thông tin đăng nhập ẩn danh/mã thông báo mù như Quyền riêng tư.
Phần khó khăn về vấn đề này là bạn cần yêu cầu nhà cung cấp dịch vụ tìm hiểu mã định danh cho người dùng mà người dùng không thể tùy ý (chọn lại) đồng thời không cho phép kẻ tấn công tháo vát xác định chính xác người dùng từ mã định danh . Giải pháp tốt nhất mà tôi có thể đưa ra cho vấn đề này là băm/PRF khóa riêng tư, điều này không nên bị cưỡng bức và do đó không làm rò rỉ danh tính đồng thời ngăn những người dùng khác giả mạo nhau thông qua phần AND của bằng chứng/ giao thức.
Cụ thể, giả sử bạn có một giao thức chứng minh không có kiến thức chung, bạn muốn chứng minh rằng người dùng biết khóa riêng của họ $x$ như vậy mà $H=\operatorname{Hash}(x)\land \exists i: \operatorname{is-public-key-of}(\text{pk}_i,x)$ giữ ở đâu $\{\text{pk}_i\}$ là tập hợp các khóa công khai của người dùng diễn đàn hiện tại và mô hình hóa hàm băm như một lời tiên tri ngẫu nhiên để không phải là một trong những hàm băm "câm" làm rò rỉ đầu vào. Một công thức thay thế của tuyên bố trên được chứng minh sẽ là $H=\operatorname{Hash}(x)\land (\bigvee_i \operatorname{is-public-key-of}(\text{pk}_i,x))$ để nhấn mạnh tính chất "HOẶC" của phần thứ hai. Tờ giấy này có vẻ như nó có thể giúp với phương pháp này.
Ngoài ra, điều tương tự cũng có thể đạt được theo các giả định khác nhau bằng cách sử dụng tính toán an toàn của nhiều bên. Cụ thể, ở đây bạn sẽ xác định một chức năng lấy từ người dùng diễn đàn khóa riêng $x$, từ nhà cung cấp dịch vụ một khóa ngẫu nhiên đối xứng tĩnh $k$ và sau đó với tư cách là đầu vào công khai, danh sách khóa công khai hiện tại của diễn đàn. Các chức năng sau đó sẽ xuất ra một chút $b$ cho biết liệu $\bigvee_i \operatorname{is-public-key-of}(\text{pk}_i,x)$ giữ và một chuỗi ngẫu nhiên $I=\operatorname{PRF}(k,x)$ làm định danh người dùng diễn đàn. Mặc dù tôi nghĩ rằng cả hai hoạt động phụ này đều có xu hướng có các giao thức chuyên biệt hiệu quả riêng lẻ, nhưng rất tiếc là tôi không nghĩ nói chung, có một cách tốt để "liên kết" các đầu vào của các giao thức này với nhau để người dùng không sử dụng đầu vào khác cho một giao thức phụ. Đối với điều này, khung 2PC giao thức hỗn hợp có thể là lựa chọn tốt nhất, ví dụ: ABY, CỬ ĐỘNG, hoặc ABY 2.0 vì chúng cho phép bạn thực hiện kiểm tra quan hệ khóa riêng tư-công khai bằng các phép toán số học và xác minh hàm băm/đánh giá PRF bằng nhị phân.
