Điểm:1

PAKE ẩn danh sử dụng tính toán của hai bên

lá cờ us

Giả sử phía khách hàng có mật khẩu bí mật $\pi$. Máy chủ có một loạt các chỉ số $0..n-1$ và một giá trị liên quan đến muối $s_i$ cho tất cả $i \in \{0,n-1\}$ gọi nó là thiết lập $S=\{s_i | tôi \in \{0,n-1\}\}$ cho mỗi khách hàng. Khách hàng muốn tính toán một hàm OPRF $f(\pi,s)$ như vậy mà anh ta không học $s$ và máy chủ không học được gì. Về cơ bản, đây là những gì OPAQUE làm cho $f(\pi,s)=H(\pi,H'(\pi)^s)$ ở đâu $H'$ băm vào một phần tử nhóm phụ.Bởi vì máy chủ chỉ nhìn thấy người bị mù $H'(\pi)$ đó là một phần tử nhóm ngẫu nhiên, nó có thể mô phỏng chế độ xem của nó và cho dù khách hàng có bao nhiêu truy vấn, nó sẽ không bao giờ học được $s$.

Nhưng tôi cần tiến thêm một bước nữa và yêu cầu nó cho phép đăng nhập ẩn danh. Đó là tôi cần một chức năng $g(i,\pi,S)=f(\pi,s_i)$ sao cho máy chủ không tìm hiểu bất cứ điều gì về một trong hai $i$ hoặc $\pi$ và khách hàng không tìm hiểu bất cứ điều gì khác về $S$ hoặc về bất kỳ yếu tố nào khác trong $S$. ít nhất là không $f(\pi,s_j)$ cho người khác $j$ cho phép một người nhắm mục tiêu nhiều tài khoản cùng một lúc bằng các cuộc tấn công từ điển/vũ phu.

Một cách để thực hiện điều này cho chức năng tương tự như trong OPAQUE là sử dụng OPAQUE cùng với chuyển giao không rõ ràng. Máy khách không cần gửi nhiều giá trị cùng một lúc mà chỉ cần sử dụng OT ở đây có nghĩa là máy chủ phải thực hiện việc tính toán kết thúc của nó. $f(\pi,s_i)$ cho mỗi $i$ I E $n$ lũy thừa/phép nhân vô hướng và cần gửi $n$ văn bản mật mã mỗi khi khách hàng cố gắng đăng nhập. Và điều này nằm ngoài các tính toán liên quan đến chính Cựu ước. Xét cho cùng, OT có thể được sử dụng để chuyển các tin nhắn tùy ý, không chỉ tính toán một số chức năng vì vậy $n$ văn bản mật mã trong trường hợp chung là hợp lý. Nhưng điều này sẽ không thực tế ở đây.

Vì vậy, có ai biết về bất kỳ công việc nào về vấn đề này hoặc đang làm bất cứ điều gì có thể đạt được điều này hiệu quả hơn trong thời gian không đổi hoặc ít nhất là thời gian tuyến tính của số lượng khách hàng trở nên thực tế. Nó có thể là thứ sử dụng một số bộ tích lũy trong $S$ mà có thể được tính toán trước hoặc một cái gì đó. Nó không nhất thiết phải có chức năng giống như trong OPAQUE, bất kỳ thứ gì có thuộc tính trên đều hoạt động.

CHỈNH SỬA: Tôi không đề xuất thực hiện ẩn danh OPAQUE đầy đủ, vì nó chứa khóa DH riêng ID ứng dụng khách được mã hóa và khóa DH công khai của máy chủ yêu cầu OT thực hiện ẩn danh. Nhưng chỉ thực hiện tính toán ẩn danh phần OPRF và thực hiện phần còn lại của trao đổi khóa một cách riêng biệt.

Điểm:1
lá cờ my

Vì vậy, có ai biết về bất kỳ công việc nào về điều này hoặc đang làm bất cứ điều gì có thể đạt được điều này hiệu quả hơn trong thời gian không đổi hoặc ít nhất là thời gian tuyến tính của số lượng khách hàng là thực tế.

Chà, với đề xuất dựa trên OPAQUE của bạn, bạn không cần tất cả các đảm bảo bảo mật của OT; bạn không quan tâm nếu khách hàng tìm hiểu về tải trọng được mã hóa cho các khách hàng khác. Do đó, Truy xuất thông tin cá nhân (PIR) là đủ, vì nó cung cấp cho bạn một đảm bảo bảo mật duy nhất mà bạn quan tâm (máy chủ không biết tải trọng được mã hóa của máy khách nào mà máy khách đang truy xuất). Bây giờ, chúng tôi không biết cách thực hiện PIR trong thời gian tuyến tính (không có giao tiếp trước với máy khách - điều đó là không thể trong trường hợp này và không giả sử có nhiều máy chủ trong đó ít nhất một máy chủ được tin cậy); tuy nhiên, tôi tin rằng hằng số tỷ lệ trên các cơ chế PIR hiện tại đủ nhỏ để biến điều này thành hiện thực.

Mặt khác, nếu bạn không ngại tiết lộ giới hạn trên của số lượng máy khách, một giải pháp thay thế thực tế có thể đặt danh sách tất cả các tải trọng của máy khách được mã hóa trên một máy chủ công cộng (được ký bởi khóa chung của máy chủ, một cách tự nhiên); bất kỳ ai cũng có thể tải xuống bất kỳ lúc nào mà không mất phí cho máy chủ.

Manish Adhikari avatar
lá cờ us
Có, tôi hiểu về truy xuất tải trọng được mã hóa của ứng dụng khách, tính ẩn danh có thể được bảo toàn bằng cách tách nó ra khỏi phép tính $f$. Nhưng câu hỏi chính của tôi là về cách tính OPRF yêu cầu OT như đảm bảo bảo mật, tôi không muốn kẻ tấn công có thể thăm dò nhiều tài khoản cho một mật khẩu cùng một lúc. Giống như PIR, nếu nó thực tế ngay cả với thời gian tuyến tính và giao tiếp, tôi không phiền khi sử dụng OT ở đây. Nếu chúng tôi không biết cách thực hiện trong thời gian tuyến tính, thì có thể hy sinh một số ẩn danh (OT cho một nhóm nhỏ khách hàng) vì tính thực tế có thể là một giải pháp thay thế.
poncho avatar
lá cờ my
@ManishAdhikari: cách dễ nhất để ngăn người khác thăm dò đồng thời nhiều tài khoản là đặt mật khẩu mà bạn cung cấp cho Opaque bao gồm tên người dùng, chẳng hạn như trong "poncho@my_password". Vì Opaque cung cấp cho bạn thuộc tính cho phép bạn chỉ kiểm tra một mật khẩu cho mỗi lần trao đổi, bao gồm cả tên người dùng, nghĩa là chúng tôi không thể kiểm tra nhiều người dùng bằng một lần trao đổi.
Manish Adhikari avatar
lá cờ us
Đó là một cách tốt. Cảm ơ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.