ก่อนอื่นให้พูดถึงส่วนโบนัส: เมื่อคุณแก้ปัญหาประเภทนี้ โดยทั่วไปคุณจะต้องใช้โปรโตคอลบางอย่างเพื่อพิสูจน์ว่าผู้ใช้ฟอรัมที่อ้างสิทธิ์นั้นเป็นส่วนหนึ่งของผู้ใช้ฟอรัมชุดปัจจุบัน เมื่อชุดของผู้ใช้ฟอรัมปัจจุบันเปลี่ยนไป คุณควรจะเรียกใช้โปรโตคอลนี้อีกครั้งเพื่อตรวจสอบว่าผู้ใช้ที่มีปัญหายังคงได้รับอนุญาตอยู่วิธีนี้ใช้งานได้ดียิ่งขึ้นหากคุณมีตัวระบุแบบสุ่มหลอกที่กำหนดขึ้นสำหรับผู้ใช้ฟอรัมแต่ละราย
สำหรับส่วนการพิสูจน์จริง มีสองตัวเลือกที่ฉันเห็น: การใช้การพิสูจน์ความรู้เป็นศูนย์ด้วยแฮชและการพิสูจน์การเป็นสมาชิกกลุ่ม หรือการใช้โปรโตคอลการคำนวณสองฝ่ายด้วย PRF และเพรดิเคตการเป็นสมาชิกกลุ่ม หากไม่มีส่วนการใช้นามแฝง นี่จะเป็นกรณีมาตรฐานสำหรับลายเซ็นแบบริงโทนหรือลายเซ็นแบบกลุ่ม ซึ่งพิสูจน์ว่าคุณสามารถสร้างลายเซ็นที่ถูกต้องภายใต้คีย์สาธารณะหนึ่งคีย์จากกลุ่มได้ อีกทางเลือกหนึ่งหากคุณสามารถโน้มน้าวให้การดำเนินการฟอรัมทำงานร่วมกันได้คือการใช้ข้อมูลประจำตัวที่ไม่ระบุชื่อ / โทเค็นที่ปิดตาเช่น ความเป็นส่วนตัวผ่าน.
ส่วนที่ยุ่งยากเกี่ยวกับเรื่องนี้คือคุณต้องให้ผู้ให้บริการเรียนรู้ตัวระบุสำหรับผู้ใช้ที่ไม่สามารถเลือกโดยพลการ (อีกครั้ง) โดยผู้ใช้ในขณะเดียวกันก็ไม่อนุญาตให้ผู้โจมตีที่มีไหวพริบสามารถระบุผู้ใช้ที่แน่นอนจากตัวระบุ . ทางออกที่ดีที่สุดที่ฉันคิดได้คือการแฮช / PRF คีย์ส่วนตัวซึ่งไม่ควรบังคับแบบเดรัจฉานและไม่รั่วไหลของข้อมูลประจำตัวในขณะที่ป้องกันผู้ใช้รายอื่นที่สวมรอยเป็นกันและกันผ่านส่วน AND ของการพิสูจน์ / มาตรการ.
สมมติว่าคุณมีโปรโตคอลการพิสูจน์ความรู้ทั่วไปเป็นศูนย์ คุณต้องการพิสูจน์ว่าผู้ใช้รู้จักรหัสส่วนตัวของพวกเขา $x$ ดังนั้น $H=\operatorname{Hash}(x)\land \exists i: \operatorname{is-public-key-of}(\text{pk}_i,x)$ ถือที่ไหน $\{\text{pk}_i\}$ คือชุดของคีย์สาธารณะของผู้ใช้ฟอรัมปัจจุบันและการสร้างแบบจำลองฟังก์ชันแฮชเป็นออราเคิลแบบสุ่มเพื่อไม่ให้เป็นหนึ่งในฟังก์ชันแฮช "ใบ้" ที่ทำให้อินพุตรั่วไหล การกำหนดทางเลือกของข้อความข้างต้นที่จะพิสูจน์จะเป็น $H=\operatorname{Hash}(x)\land (\bigvee_i \operatorname{is-public-key-of}(\text{pk}_i,x))$ เพื่อเน้น "หรือ" - ลักษณะของส่วนที่สอง กระดาษแผ่นนี้ ดูเหมือนว่าวิธีนี้จะช่วยได้
อีกทางเลือกหนึ่ง ควรทำเช่นเดียวกันภายใต้สมมติฐานที่แตกต่างกันโดยใช้การคำนวณหลายฝ่ายที่ปลอดภัย โดยเฉพาะอย่างยิ่ง คุณจะต้องกำหนดฟังก์ชันที่รับคีย์ส่วนตัวจากผู้ใช้ฟอรัม $x$จากผู้ให้บริการคีย์สุ่มแบบสมมาตรคงที่ $k$ จากนั้นเมื่อป้อนข้อมูลสาธารณะรายการปัจจุบันของคีย์สาธารณะของฟอรัม ฟังก์ชันการทำงานจะออกมาเล็กน้อย $ข$ แสดงว่า $\bigvee_i \operatorname{is-public-key-of}(\text{pk}_i,x)$ ถือและสตริงสุ่ม $I=\ชื่อผู้ประกอบการ{PRF}(k,x)$ เป็นตัวระบุผู้ใช้ฟอรัม แม้ว่าฉันคิดว่าการดำเนินการย่อยทั้งสองนี้มีแนวโน้มที่จะมีโปรโตคอลเฉพาะที่มีประสิทธิภาพแยกจากกัน แต่น่าเสียดายที่ฉันไม่มี คิด โดยทั่วไปมีวิธีที่ดีในการ "ผูก" อินพุตกับโปรโตคอลเหล่านี้เข้าด้วยกัน เพื่อให้ผู้ใช้ไม่ใช้อินพุตที่แตกต่างกันสำหรับโปรโตคอลย่อยหนึ่งรายการ สำหรับสิ่งนี้ เฟรมเวิร์ก 2PC แบบผสมโปรโตคอลน่าจะเป็นตัวเลือกที่ดีที่สุด เช่น เอบี, การเคลื่อนไหว, หรือ ABY 2.0 เนื่องจากอนุญาตให้คุณทำการตรวจสอบความสัมพันธ์ของคีย์ส่วนตัวและสาธารณะด้วยการดำเนินการทางคณิตศาสตร์และการตรวจสอบแฮช / การประเมิน PRF ด้วยไบนารี