ความเป็นไปไม่ได้ของโครงร่าง "blind HMAC" ที่ปลอดภัย ซึ่งเป็นอะนาล็อกของลายเซ็นตาบอดที่ใช้ HMAC นั้นเป็นที่ทราบกันดี (ตามที่ฉันเข้าใจ โดยพื้นฐานแล้วเกิดจากการที่ผู้ใช้ไม่สามารถตรวจสอบความถูกต้องของลายเซ็นที่ได้รับเทียบกับรหัสสาธารณะสำหรับผู้ลงนาม ดังนั้น ไม่สามารถแน่ใจได้ว่าผู้ลงนามไม่ได้ใช้คีย์การเซ็นชื่อหลายคีย์ และภายหลัง "ยกเลิกการปกปิด" โดยพิจารณาว่าคีย์ใดที่ใช้ได้สำหรับลายเซ็นที่กำหนด)
อย่างไรก็ตาม จากประสิทธิภาพและมุมมองขนาดลายเซ็น/MAC นั้น HMAC มักจะดีกว่าลายเซ็นที่ผู้ตรวจสอบที่ถือคีย์สมมาตรของผู้ลงนามนั้นยอมรับได้ตัวอย่างเช่น ลายเซ็น BLS (ตาบอดหรือไม่ก็ได้) ในโหมดขนาดลายเซ็นขั้นต่ำที่มีเส้นโค้ง BLS12-381 ใช้ 384 บิตโดยมีเป้าหมายความปลอดภัย 128 บิต - ดูเหมือนว่าจะค่อนข้างสั้นตามมาตรฐานลายเซ็น เปรียบเทียบแล้วดูเหมือนว่า แฮช 128 บิตสามารถให้ความปลอดภัย 128 บิตเมื่อใช้ HMAC
ในสถานการณ์เช่นนี้ แบบแผนการตรวจสอบสิทธิ์แบบตาบอด "กึ่ง HMAC" จะใช้งานได้หรือไม่ สิ่งที่ต้องการ:
- ผู้ใช้สร้างและซ่อนข้อความด้วยรูปแบบลายเซ็นแบบปกติ ส่งไปยังผู้ลงนาม
- ผู้ลงนามลงนามในข้อความที่ปิดตา ส่งกลับไปยังผู้ใช้
- ผู้ใช้ยกเลิกการซ่อนและยืนยันกับคีย์สาธารณะของผู้ลงนาม เช่นเดียวกับลายเซ็นตาบอดปกติ - "blind HMAC" ตามที่เสนอและพิสูจน์แล้วว่าไม่ปลอดภัยไม่สามารถทำเช่นนี้ได้ แต่สามารถทำได้ที่นี่ เนื่องจากการเซ็นชื่อแบบตาบอดจะทำโดยใช้แบบแผนลายเซ็นตาบอดแบบ assymetric แบบปกติ และการรับรองความถูกต้องตามแฮชจะใช้ในภายหลังเท่านั้น
- ผู้ใช้สร้างแฮชของข้อความและลายเซ็น (แทนที่จะเป็นของข้อความและคีย์เหมือนใน HMAC) และแนบไปกับข้อความ
- ผู้ใช้ส่งข้อความและแฮชไปยังผู้ตรวจสอบ
- ผู้ตรวจสอบได้รับข้อความและลงนามโดยอิสระด้วยรหัสส่วนตัวของผู้ลงนาม (ใช้ร่วมกับผู้ตรวจสอบเนื่องจากคีย์สมมาตรอยู่ในแผน HMAC)
- ตัวตรวจสอบจะเปรียบเทียบแฮชที่ผู้ใช้ระบุกับแฮชที่สร้างขึ้น
- หากแฮชตรงกัน แสดงว่าผู้ใช้ได้พิสูจน์ว่าผู้ลงนามได้ลงนามในข้อความ โดยไม่จำเป็นต้องรวมลายเซ็นที่ยาวกว่าแฮช
ดูเหมือนว่ารูปแบบดังกล่าวสามารถลดค่าใช้จ่ายในการจัดเก็บและโอนลายเซ็นที่ค่อนข้างยาวไปยังเครื่องตรวจสอบได้นอกจากนี้ ดูเหมือนว่าข้อกำหนดเกี่ยวกับฟังก์ชันแฮชอาจมีน้อยผิดปกติ ตัวอย่างเช่น การโจมตีพรีอิมเมจบนฟังก์ชันแฮชจะไม่ดูเหมือนเป็นภัยคุกคาม เนื่องจากทั้งสองฝ่ายทราบข้อความที่ใช้สร้างแล้ว และจะไม่ โจมตีโดยที่ฝ่ายใดฝ่ายหนึ่งสามารถสร้างการชนกันของแฮช (แฮชใช้เพื่อพิสูจน์ว่าผู้ใช้มีลายเซ็นที่ถูกต้องสำหรับข้อความเท่านั้น ผู้ใช้จำเป็นต้องรู้แฮชของข้อความของตน และ ลายเซ็นที่ถูกต้องสำหรับค้นหาการชนกันของแฮชซึ่งส่งผลให้แฮชเหมือนกันเพื่อให้ตรงกับแฮชที่สร้างโดยตัวตรวจสอบ) จริงๆ แล้ว แฮชจำเป็นต้องปลอดภัยต่อผู้ใช้เท่านั้นที่สามารถคาดเดาแฮชของข้อความและลายเซ็นที่ถูกต้องได้โดยไม่ได้รับลายเซ็นนั้น นั่นคือ การบังคับแฮชที่ถูกต้องสำหรับข้อความ "ออนไลน์" จะต้องยากพอสมควร สื่อสารกับผู้ตรวจสอบ การบังคับแฮชแบบออฟไลน์ดูเหมือนจะใช้ไม่ได้จริง เนื่องจากผู้ใช้ไม่สามารถตรวจสอบการเดาแฮชกับข้อความออฟไลน์ได้หากไม่มี อีกด้วย ความสามารถในการย้อนกลับแฮชเป็นลายเซ็น (ยาวกว่ามากโดยบังเอิญ) และตรวจสอบลายเซ็นกับรหัสสาธารณะ - พวกเขาน่าจะทำได้ดีกว่าในการพยายามบังคับลายเซ็นที่ถูกต้องหรือรหัสการลงนามสำหรับลายเซ็นตาบอด แบบแผนจากนั้นสร้างแฮชของสิ่งนั้น
ฉันไม่พบการอ้างอิงถึงรูปแบบการตรวจสอบสิทธิ์แบบตาบอดซึ่งทำงานในลักษณะนี้ โครงการดังกล่าวเป็นไปได้หรือไม่? มีข้อบกพร่องใด ๆ ที่เห็นได้ชัด ความปลอดภัยหรืออื่น ๆ หรือไม่?
TL;DR สามารถหลีกเลี่ยงข้อบกพร่องด้านความปลอดภัยที่ทราบของแบบแผน HMAC แบบตาบอดได้ โดยไม่ต้องมีผลกระทบด้านขนาดลายเซ็นของแบบแผนลายเซ็นแบบตาบอดโดยใช้แบบแผนลายเซ็นแบบตาบอดเมื่อลงนาม แต่ให้ผู้ใช้แฮชลายเซ็นและสร้างลายเซ็นนั้นใหม่และ แฮชที่ฝั่งผู้ตรวจสอบโดยใช้คีย์ส่วนตัวของผู้ลงนาม แล้วเปรียบเทียบแฮช?