TL;DR

  • การเข้ารหัสแบบเกณฑ์แบ่งความสามารถในการดำเนินการเข้ารหัสระหว่างผู้เข้าร่วมหลายคน การดำเนินการจะสำเร็จได้ก็ต่อเมื่อเกณฑ์ที่ได้รับอนุญาตร่วมมือกัน ในการลงนามแบบเกณฑ์ ผู้เข้าร่วมจะร่วมกันสร้างลายเซ็นดิจิทัลปกติภายใต้กุญแจสาธารณะของกลุ่ม โดยไม่ต้องสร้างกุญแจส่วนตัวที่สมบูรณ์ขึ้นมาก่อน
  • สัญลักษณ์ t-of-n หมายความว่าจำเป็นต้องมีผู้เข้าร่วมอย่างน้อย t จาก n เพื่อดำเนินการตามวัตถุประสงค์ ระบบที่ปลอดภัยมักมีเป้าหมายเพื่อปกป้องความลับของกุญแจจากการทุจริตน้อยกว่า t ครั้ง และรักษาความพร้อมใช้งานไว้ได้ตราบใดที่ยังมีผู้เข้าร่วมที่เหมาะสมอย่างน้อย t คนออนไลน์อยู่ การรับประกันเหล่านี้ขึ้นอยู่กับผู้โจมตีที่กำหนดไว้ เครือข่าย และแบบจำลองการนำไปใช้
  • การแบ่งปันความลับแบบ Shamir แบ่งความลับที่เก็บไว้เพื่อให้ threshold สามารถสร้างมันขึ้นใหม่ได้ การแบ่งปันแบบ Shamir ธรรมดาไม่ได้กำหนดวิธีคำนวณลายเซ็น ECDSA, Schnorr หรือ EdDSA ในขณะที่ความลับยังคงถูกแบ่งอยู่ โปรโตคอลลายเซ็น threshold อาจใช้ส่วนแบ่งแบบ Shamir ภายใน แต่เพิ่มการคำนวณแบบโต้ตอบ การพิสูจน์ การจัดการ nonce และการตรวจสอบ ดังนั้นการสร้างขึ้นใหม่จึงไม่จำเป็น
  • บางครั้ง ในระบบที่ใช้ DKG ผู้เข้าร่วมจะสร้างส่วนแบ่งและกุญแจสาธารณะของกลุ่มร่วมกัน ดังนั้นตามสมมติฐานของโปรโตคอล ผู้เข้าร่วมคนใดคนหนึ่งจะไม่สามารถรู้กุญแจส่วนตัวที่สมบูรณ์ได้ อย่างไรก็ตาม ผู้จัดจำหน่ายที่เชื่อถือได้ การแปลงกุญแจที่นำเข้า หรือการสำรองข้อมูลแบบสร้างใหม่ อาจสร้างกุญแจที่สมบูรณ์ได้ในช่วงการตั้งค่าหรือการกู้คืน คำตอบขึ้นอยู่กับวงจรชีวิต ไม่ใช่ป้ายการตลาด
ในบล็อกเดียว

MPC เป็นสาขาที่กว้างขวาง การลงนามแบบ threshold เป็นหนึ่งในแอปพลิเคชันของ MPC ไม่ใช่คำพ้องความหมายสำหรับระบบการคำนวณหลายฝ่ายทุกประเภท ลายเซ็นเกณฑ์ t-of-n โดยปกติต้องการผู้เข้าร่วมอย่างน้อย t จาก n คนเพื่อสร้างลายเซ็น และมีวัตถุประสงค์เพื่อรักษาความลับให้ปลอดภัยจากการทุจริตของจำนวนผู้เข้าร่วมน้อยกว่า t ต้องพิจารณาทั้งเกณฑ์ความพร้อมใช้งานและเกณฑ์ความลับ การแบ่งปันความลับแบบ Shami…

การเข้ารหัสแบบเกณฑ์ (Threshold Cryptography) คืออะไร?

ตอบด่วน

การเข้ารหัสแบบเกณฑ์แบ่งความสามารถในการดำเนินการเข้ารหัสระหว่างผู้เข้าร่วมหลายคน การดำเนินการจะสำเร็จได้ก็ต่อเมื่อเกณฑ์ที่ได้รับอนุญาตร่วมมือกัน ในการลงนามแบบเกณฑ์ ผู้เข้าร่วมจะร่วมกันสร้างลายเซ็นดิจิทัลปกติภายใต้กุญแจสาธารณะของกลุ่ม โดยไม่ต้องสร้างกุญแจส่วนตัวที่สมบูรณ์ขึ้นมาก่อน

กุญแจลายเซ็นแบบดั้งเดิมเป็นอำนาจที่รวมศูนย์ ผู้ที่สามารถใช้กุญแจส่วนตัวได้สามารถลงลายเซ็นได้ และผู้ที่สูญเสียกุญแจส่วนตัวไปอย่างถาวรอาจสูญเสียสิทธิ์การเข้าถึง สำรองข้อมูลช่วยปรับปรุงความพร้อมใช้งาน แต่สร้างสำเนาเพิ่มเติมของอำนาจเดียวกัน การเข้ารหัสแบบเกณฑ์เปลี่ยนโครงสร้าง: ผู้เข้าร่วมถือส่วนแบ่ง และการดำเนินการเข้ารหัสถูกคำนวณร่วมกัน เป้าหมายคือทำให้อุปกรณ์ ผู้ดำเนินการ หรือการละเมิดเพียงอย่างเดียวไม่เพียงพอสำหรับการขโมยหรือการสูญเสียอย่างถาวร

คำว่า threshold อธิบายนโยบาย เช่น 2-of-3 หรือ 3-of-5 ในออกแบบการลงนามแบบ 2-of-3 ผู้เข้าร่วมที่ได้รับอนุญาตสองคนใดก็ตามสามารถดำเนินการให้เสร็จสิ้นได้ ผู้เข้าร่วมเพียงคนเดียวไม่ควรสามารถลงนามหรือทราบความลับพื้นฐานได้ ส่วนแบ่งอาจถูกเก็บไว้บนอุปกรณ์ โมดูลความปลอดภัยฮาร์ดแวร์ เซิร์ฟเวอร์ ระบบออฟไลน์ หรืออยู่กับบุคคลต่าง ๆ สถาปัตยกรรมมีความสำคัญไม่แพ้การคำนวณ: ส่วนแบ่งสามส่วนที่ควบคุมผ่านผู้ดูแลระบบคลาวด์เพียงคนเดียวอาจทำงานเหมือนโดเมนความล้มเหลวเดียว แทนที่จะเป็นสามฝ่ายอิสระ

MPC มีขอบเขตกว้างกว่าการลงนามแบบ threshold การคำนวณหลายฝ่ายที่ปลอดภัย (Secure Multi-Party Computation) ศึกษาว่าฝ่ายต่าง ๆ สามารถประเมินฟังก์ชันบนข้อมูลส่วนตัวได้อย่างไร ในขณะที่ควบคุมสิ่งที่ถูกเปิดเผย การสร้างกุญแจแบบ threshold การลงนาม การถอดรหัส และการสร้างค่าสุ่ม เป็นแอปพลิเคชันเฉพาะทาง ดังนั้น กระเป๋าเงินที่โฆษณาว่าเป็น "MPC" อาจใช้โปรโตคอล ค่า threshold การออกแบบการกู้คืน และโมเดลความปลอดภัยที่แตกต่างกันอย่างมาก การติดฉลากเพียงอย่างเดียวจึงบอกได้น้อยมากเกี่ยวกับความรับประกันที่แท้จริง

t-of-n รับประกันอะไรจริงๆ?

ตอบด่วน

สัญลักษณ์ t-of-n หมายความว่าจำเป็นต้องมีผู้เข้าร่วมอย่างน้อย t จาก n เพื่อดำเนินการตามวัตถุประสงค์ ระบบที่ปลอดภัยมักมีเป้าหมายเพื่อปกป้องความลับของกุญแจจากการทุจริตน้อยกว่า t ครั้ง และรักษาความพร้อมใช้งานไว้ได้ตราบใดที่ยังมีผู้เข้าร่วมที่เหมาะสมอย่างน้อย t คนออนไลน์อยู่ การรับประกันเหล่านี้ขึ้นอยู่กับผู้โจมตีที่กำหนดไว้ เครือข่าย และแบบจำลองการนำไปใช้

เกณฑ์ (threshold) ไม่ใช่การรับประกันแบบสากล ผู้เชี่ยวชาญแบ่งการรับประกันออกเป็นความลับ (secrecy), ความไม่สามารถปลอมแปลงได้ (unforgeability), ความพร้อมใช้งาน (availability), ความทนทาน (robustness) และความรับผิดชอบ (accountability) การออกแบบหนึ่งอาจปกป้องความลับของกุญแจได้ แต่ยังอนุญาตให้ผู้เข้าร่วมที่มีเจตนาร้ายหนึ่งคนขัดขวางทุกความพยายามในการลงนามได้ มันอาจระบุตัวผู้ก่อกวนได้ แต่ยังคงไม่สามารถเสร็จสิ้นการลงนามได้หากไม่เปลี่ยนผู้เข้าร่วมนั้น มันอาจทนต่อผู้ลงนามที่ถูกบุกรุกหนึ่งคนภายใต้แบบจำลองผู้โจมตีแบบคงที่ (static adversary model) แต่จะล้มเหลวหากผู้โจมตีบุกรุกผู้ลงนามต่าง ๆ ตามเวลา

คุณสมบัติคำถามที่มันตอบความสำคัญ
ความลับ / ความเป็นส่วนตัวของกุญแจการแบ่งส่วนน้อยกว่า t จะเปิดเผยกุญแจส่วนตัวหรือข้อมูลเพียงพอที่จะสร้างกุญแจนั้นขึ้นใหม่ได้หรือไม่?ปกป้องหน่วยงานที่รับผิดชอบจากการถูกเจาะระบบด้วยข้อมูลที่น้อยกว่าเกณฑ์
ไม่สามารถปลอมแปลงได้ผู้โจมตีสามารถสร้างลายเซ็นที่ถูกต้องได้หรือไม่ โดยไม่มีค่าเกณฑ์ที่ได้รับอนุญาต?เป้าหมายหลักด้านความปลอดภัยของลายเซ็นแบบเกณฑ์
ความมีชีวิตผู้เข้าร่วมที่ซื่อสัตย์สามารถดำเนินการให้เสร็จสิ้นได้หรือไม่ เมื่อมีผู้เข้าร่วมเพียงพอ?กระเป๋าเงินที่ปลอดภัยแต่หยุดทำงานอย่างถาวรจะไม่สามารถใช้งานได้
ความทนทานโปรโตคอลสามารถดำเนินการจนเสร็จสิ้นได้หรือไม่ แม้จะมีข้อความที่ผิดรูปแบบหรือผู้เข้าร่วมที่มีเจตนาร้าย แทนที่จะหยุดการทำงานเพียงอย่างเดียว?กำหนดความทนทานต่อการโจมตีแบบปฏิเสธการให้บริการ (Denial of Service)
การยกเลิกที่สามารถระบุได้หากโปรโตคอลล้มเหลว ผู้เข้าร่วมที่ซื่อสัตย์สามารถระบุได้ว่าผู้เข้าร่วมใดมีพฤติกรรมผิดปกติหรือไม่?สนับสนุนการตัดออก การรับผิดชอบ และการฟื้นฟูระบบสนับสนุนการตัดออก การรับผิดชอบ และการฟื้นฟูระบบ
ความปลอดภัยเชิงรุกสามารถอัปเดตข้อมูลร่วมได้หรือไม่ เพื่อป้องกันไม่ให้การละเมิดที่เกิดขึ้นในช่วงเวลาต่าง ๆ สะสมไปอย่างไม่มีที่สิ้นสุด?จำกัดผู้โจมตีให้อยู่ในหน้าต่างการอัปเดตเพียงหนึ่งครั้งภายใต้โมเดลนี้
ความปลอดภัยแบบปรับตัวได้จะเกิดอะไรขึ้นหากผู้โจมตีเลือกว่าจะโจมตีใครระหว่างหรือหลังจากการสังเกตเซสชันโปรโตคอล?จำลองระบบผลิตที่มีอายุการใช้งานยาวนานได้ใกล้เคียงยิ่งขึ้น
ความสามารถในการประกอบการรับประกันยังคงมีผลอยู่แม้มีเซสชันหลายเซสชันที่ทำงานพร้อมกันและโปรโตคอลที่เกี่ยวข้องหรือไม่?สำคัญสำหรับบริการที่ลงนามในขนาดใหญ่

แม้แต่คำกล่าว "การเปิดเผยส่วนแบ่งน้อยกว่า t จะไม่เปิดเผยข้อมูลใดๆ" ก็จำเป็นต้องมีขอบเขตที่ชัดเจน การแบ่งปันความลับแบบ Shamir ที่สมบูรณ์แบบให้คำกล่าวทางทฤษฎีข้อมูลเกี่ยวกับส่วนแบ่งทางคณิตศาสตร์ ส่วนกระเป๋าเงินแบบ threshold ที่ถูกนำไปใช้งานจริงยังสร้างบันทึกการดำเนินการ (transcripts), คำมั่นสัญญาสาธารณะ (public commitments), บันทึก (logs), ข้อมูลเวลา (timing information) และข้อความแสดงข้อผิดพลาด (error messages) ระบบรอบข้างเหล่านี้อาจรั่วไหลข้อมูลเมตาดาต้า, เปิดโอกาสให้เกิดการโจมตีแบบเลือกอินพุต (chosen-input attacks) หรือเปิดเผยข้อบกพร่องในการพัฒนา โดยไม่ขัดแย้งกับทฤษฎีการแบ่งปันความลับแบบอุดมคติ

ข้อสรุป: t-of-n บอกคุณเกี่ยวกับจำนวนเสียงที่จำเป็น (quorum) แต่ไม่บอกคุณเกี่ยวกับแบบจำลองผู้โจมตี (adversary model) ว่าผู้ลงนามที่มีเจตนาร้ายสามารถหยุดระบบได้หรือไม่ ส่วนแบ่งสามารถอัปเดตได้หรือไม่ หรือว่าโค้ดได้รับการตรวจสอบอย่างอิสระแล้วหรือไม่

ทำไมการแบ่งปันความลับแบบ Shamir จึงไม่เหมือนกับการลงนามแบบ threshold?

ตอบด่วน

การแบ่งปันความลับแบบ Shamir แบ่งความลับที่เก็บไว้เพื่อให้ threshold สามารถสร้างมันขึ้นใหม่ได้ การแบ่งปันแบบ Shamir ธรรมดาไม่ได้กำหนดวิธีคำนวณลายเซ็น ECDSA, Schnorr หรือ EdDSA ในขณะที่ความลับยังคงถูกแบ่งอยู่ โปรโตคอลลายเซ็น threshold อาจใช้ส่วนแบ่งแบบ Shamir ภายใน แต่เพิ่มการคำนวณแบบโต้ตอบ การพิสูจน์ การจัดการ nonce และการตรวจสอบ ดังนั้นการสร้างขึ้นใหม่จึงไม่จำเป็น

วิธีการสร้างของชาเมียร์ในปี 1979 แสดงความลับเป็นค่าคงที่ของพหุนามสุ่ม ผู้เข้าร่วมแต่ละคนจะได้รับจุดหนึ่งบนพหุนามนั้น หากมีจุดเพียงพอ สามารถทำการแทรกค่าพหุนามและกู้คืนความลับได้ แต่หากมีจุดน้อยเกินไป ความลับจะยังคงไม่ถูกกำหนด นี่เป็นวิธีที่สง่างามและทรงพลังในการปกป้องข้อมูลสำรอง ข้อมูลที่ฝากไว้กับผู้รับฝาก และรหัสลับสำหรับการกู้คืน

ข้อจำกัดในการใช้งานจะปรากฏขึ้นเมื่อจำเป็นต้องใช้ความลับ หากเครื่องมือเดียวที่มีอยู่คือวิธีการสร้างใหม่ของชาเมียร์ ผู้เข้าร่วมที่ได้รับอนุญาตจะรวมส่วนย่อยของตนบนเครื่องเดียว เพื่อรับกุญแจส่วนตัวเต็มรูปแบบและเรียกใช้อัลกอริทึมการลงนามทั่วไป ในขณะนั้น อุปกรณ์การสร้างใหม่ หน่วยความจำ บันทึกกระบวนการ พื้นที่สวอป และผู้ดำเนินการจะกลายเป็นจุดเสี่ยงเดียว ความลับสามารถถูกลบออกได้หลังจากนั้น แต่พื้นที่เสี่ยงต่อการโจมตีได้เกิดขึ้นแล้ว

ลายเซ็นแบบเกณฑ์ (threshold signature) ดำเนินการคำนวณทางคณิตศาสตร์บนส่วนแบ่ง ผู้เข้าร่วมสร้างค่าส่วนย่อย พิสูจน์หรือตรวจสอบว่าค่าเหล่านั้นถูกต้องตามรูปแบบ และรวมผลลัพธ์ส่วนย่อยเหล่านั้นเป็นลายเซ็น กุญแจลงนามแบบสมบูรณ์ไม่จำเป็นต้องปรากฏในระหว่างเซสชันการลงนาม ระบบเกณฑ์หลายระบบใช้การแบ่งพหุนามแบบ Shamir เป็นส่วนประกอบหนึ่ง ความแตกต่างที่แท้จริงอยู่ระหว่างการเก็บรักษาความลับพร้อมการกู้คืนในมือหนึ่ง กับโปรโตคอลการลงนามแบบกระจายเต็มรูปแบบในอีกมือหนึ่ง

ความสามารถการสำรองข้อมูลแบบ Shamir ธรรมดาลายเซ็นแบบเกณฑ์
เก็บรักษาความลับในหลายสถานที่ใช่ใช่, ในรูปแบบการแบ่งปันกุญแจแบบเรียลไทม์หรือสถานะโปรโตคอล
ใช้จำนวนน้อยกว่าค่าเกณฑ์ไม่สามารถสร้างใหม่ได้ไม่มีลายเซ็นที่ถูกต้องตามแบบจำลองความปลอดภัย
ลงนามโดยไม่สร้างกุญแจใหม่ไม่, ไม่สามารถทำได้ด้วยตัวเองใช่.
สร้างลายเซ็นธรรมดาหนึ่งลายเซ็นได้เฉพาะหลังจากสร้างกุญแจใหม่และลงลายมือชื่อแบบปกติแล้วเท่านั้นใช่ โดยรวมส่วนแบ่งลายเซ็นเข้าด้วยกัน
จำเป็นต้องมีการควบคุม nonce และ transcriptไม่จำเป็นสำหรับการเก็บรักษาเพียงอย่างเดียวใช่; สิ่งเหล่านี้เป็นหัวใจสำคัญของความปลอดภัยในการลงนาม
เปลี่ยนผู้เข้าร่วมโดยไม่เปลี่ยนกุญแจสาธารณะต้องมีการกระบวนการแบ่งปันใหม่ที่ชัดเจนต้องมีการควบคุม nonce และ transcriptไม่ใช้สำหรับการจัดเก็บข้อมูลเพียงอย่างเดียวใช่; สิ่งเหล่านี้เป็นหัวใจสำคัญของความปลอดภัยในการลงนามเปลี่ยนผู้เข้าร่วมโดยไม่เปลี่ยนกุญแจสาธารณะต้องมีการกระบวนการแบ่งปันใหม่ที่ชัดเจนทำได้เฉพาะเมื่อระบบสนับสนุนการรีเฟรชหรือการแชร์ใหม่
เหมาะสมที่สุดการสำรองข้อมูลแบบเย็นและการกู้คืนหลังภัยพิบัติการลงนามในการดำเนินงานซ้ำๆ ด้วยอำนาจที่กระจายตัว

กุญแจส่วนตัวที่สมบูรณ์เคยมีอยู่จริงหรือไม่?

ตอบด่วน

บางครั้ง ในระบบที่ใช้ DKG ผู้เข้าร่วมจะสร้างส่วนแบ่งและกุญแจสาธารณะของกลุ่มร่วมกัน ดังนั้นตามสมมติฐานของโปรโตคอล ผู้เข้าร่วมคนใดคนหนึ่งจะไม่สามารถรู้กุญแจส่วนตัวที่สมบูรณ์ได้ อย่างไรก็ตาม ผู้จัดจำหน่ายที่เชื่อถือได้ การแปลงกุญแจที่นำเข้า หรือการสำรองข้อมูลแบบสร้างใหม่ อาจสร้างกุญแจที่สมบูรณ์ได้ในช่วงการตั้งค่าหรือการกู้คืน คำตอบขึ้นอยู่กับวงจรชีวิต ไม่ใช่ป้ายการตลาด

Threshold signature lifecycle diagram. It compares trusted-dealer or imported-key setup with distributed key generation, then shows live shares, participant validation, nonce commitments or preprocessing, signature-share generation, aggregation and ordinary chain verification. A warning explains that the full key may exist in dealer or import paths but not in a correctly executed DKG path.
รูป 2. คำกล่าวว่า "กุญแจไม่เคยมีอยู่" เป็นความจริงเฉพาะสำหรับวงจรชีวิตที่ออกแบบมาเพื่อหลีกเลี่ยงการมีกุญแจครบถ้วนในขั้นตอนการตั้งค่า การลงนาม การสำรองข้อมูล และการกู้คืน

ผู้จัดจำหน่ายที่เชื่อถือได้

ผู้จัดจำหน่ายสร้างกุญแจส่วนตัวแบบปกติ สร้างส่วนแบ่ง และแจกจ่ายส่วนแบ่งเหล่านั้น สิ่งนี้อาจปลอดภัยได้หากผู้จัดจำหน่ายใช้ความสุ่มที่แข็งแกร่ง ตรวจสอบความถูกต้องของผู้เข้าร่วมทุกคน ตรวจสอบคำมั่นสัญญาในการแบ่งปัน และลบความลับต้นฉบับและส่วนแบ่งที่ไม่ได้ใช้อย่างน่าเชื่อถือ อย่างไรก็ตาม สิ่งนี้สร้างช่วงเวลาและบุคคลที่มีความรู้เกี่ยวกับกุญแจแบบครบถ้วน RFC 9591 วางการสร้างกุญแจไว้นอกโปรโตคอล FROST หลัก และรวมขั้นตอนผู้จัดจำหน่ายที่เชื่อถือได้ไว้เพียงในส่วนภาคผนวกเท่านั้น

การสร้างกุญแจแบบกระจาย

โปรโตคอล DKG อนุญาตให้ผู้เข้าร่วมร่วมกันสร้างค่าสุ่มและร่วมกันสร้างส่วนแบ่งรวมถึงกุญแจสาธารณะร่วม ไม่มีฝ่ายใดควรทราบกุญแจส่วนตัวที่สอดคล้องกัน ตราบใดที่โปรโตคอลถูกนำไปใช้อย่างถูกต้องและไม่เกินเกณฑ์การทุจริต DKG ไม่ใช่อัลกอริทึมเดียว: แผนการต่าง ๆ มีสมมติฐานที่แตกต่างกันเกี่ยวกับการกระจายข้อมูล ช่องทางที่ผ่านการตรวจสอบความถูกต้อง การร้องเรียน ฝ่ายที่มีเจตนาร้าย และความพร้อมของผู้เข้าร่วม

การนำเข้ากุญแจที่มีอยู่

สถาบันอาจต้องการรักษาที่อยู่ที่มีอยู่ ประวัติบัญชี หรือกุญแจสาธารณะไว้ บางโปรโตคอลสนับสนุนการแปลงหรือแบ่งปันกุญแจที่มีอยู่ กระบวนการนี้อาจต้องการให้เจ้าของกุญแจจัดการกับกุญแจทั้งหมด หรืออาจใช้โปรโตคอลการนำเข้าที่เฉพาะทาง ประวัติความปลอดภัยก่อนการนำเข้ายังคงมีความสำคัญ: การแจกจ่ายกุญแจไม่สามารถยกเลิกการคัดลอก การถ่ายภาพ การสำรองข้อมูล หรือการรั่วไหลของข้อมูลที่เกิดขึ้นก่อนหน้านี้

การกู้คืนและการสร้างใหม่ในสถานการณ์ฉุกเฉิน

ระบบบางระบบเก็บรักษาเส้นทางฉุกเฉิน (break-glass path) ที่สามารถสร้างกุญแจใหม่จากข้อมูลสำรอง ซึ่งสามารถปรับปรุงการกู้คืนหลังภัยพิบัติได้ แต่ในขณะเดียวกันก็อาจทำให้กุญแจเดียวถูกเปิดเผยอีกครั้ง ซึ่งเป็นการออกแบบแบบเกณฑ์ที่พยายามหลีกเลี่ยง ระบบอื่น ๆ ไม่จัดให้มีเส้นทางสร้างใหม่โดยเจตนา และกำหนดให้มีเกณฑ์จำนวนผู้เข้าร่วมที่ใช้งานอยู่สำหรับทุกการดำเนินการกู้คืน ทั้งสองวิธีนี้ไม่ได้ถูกต้องโดยอัตโนมัติ การเลือกควรเป็นไปอย่างชัดเจน ผ่านการทดสอบ และรวมไว้ในแบบจำลองภัยคุกคาม

MPC สร้างลายเซ็นเดียวจากหลายส่วนแบ่งได้อย่างไร?

ตอบด่วน

ฝ่ายต่างๆ ตกลงกันเกี่ยวกับข้อความและเซสชันที่แน่นอน สร้างความสุ่มแบบใช้ครั้งเดียวหรือคำมั่นสัญญา คำนวณส่วนแบ่งลายเซ็นจากส่วนแบ่งส่วนตัวของพวกเขา ตรวจสอบส่วนแบ่งเหล่านั้นและรวมเข้าด้วยกัน ผลลัพธ์คือลายเซ็นมาตรฐานภายใต้กุญแจสาธารณะของกลุ่ม โปรโตคอลจะเปิดเผยลายเซ็นสุดท้ายและข้อมูลเมตาดาต้าใดๆ ที่แอปพลิเคชันเปิดเผย ไม่ใช่กุญแจส่วนตัวทั้งหมด

ลายเซ็นดิจิทัลคือความสัมพันธ์ทางคณิตศาสตร์ระหว่างข้อความ กุญแจสาธารณะ และวัสดุลงนามลับ โปรโตคอลแบบเกณฑ์ (Threshold protocols) ใช้ประโยชน์จากพีชคณิตของระบบลายเซ็น หรือใช้เครื่องมือการคำนวณที่ปลอดภัยทั่วไป เพื่อให้ผู้เข้าร่วมแต่ละคนมีส่วนร่วมในความสัมพันธ์ดังกล่าวโดยไม่เปิดเผยส่วนข้อมูลป้อนเข้าของตนเอง รายละเอียดมีความแตกต่างกันอย่างชัดเจนระหว่างลายเซ็นแบบ Schnorr และ ECDSA แต่ขั้นตอนการทำงานมีขั้นตอนที่คล้ายคลึงกัน

  • การสร้างเซสชัน ระบบกำหนดกุญแจกลุ่ม ชุดผู้เข้าร่วม ค่าเกณฑ์ ข้อความที่แน่นอน ดิจิสต์การลงนามเฉพาะโซ่ เวอร์ชันโปรโตคอล และตัวระบุเซสชันที่ไม่ซ้ำกัน
  • การตรวจสอบความถูกต้องของข้อมูลเข้า ผู้เข้าร่วมแต่ละคนตรวจสอบว่าข้อความนั้นถูกต้องทางไวยากรณ์และได้รับอนุญาตตามนโยบาย โปรโตคอลแบบ threshold ไม่ควรกลายเป็น oracle การลงนามสำหรับข้อมูลเข้าที่สุ่ม
  • การเตรียม nonce หรือการเตรียมลายเซ็นล่วงหน้า ผู้เข้าร่วมสร้างค่าลับใช้ครั้งเดียว (one-time secret values), คำมั่นสัญญา (commitments) และในบางระบบ ECDSA ยังสร้างวัสดุการคูณ (multiplication material) ด้วย ค่าเหล่านี้ต้องเป็นค่าที่ไม่ซ้ำกัน ถูกผูกกับเซสชันอย่างถูกต้อง และได้รับการปกป้องเหมือนวัสดุกุญแจ
  • การสร้างส่วนแบ่งลายเซ็น (Signature-share generation). ผู้เข้าร่วมอย่างน้อย t คนจะรวมส่วนแบ่งส่วนตัวของตนกับบันทึกการสนทนาส่วนกลางเพื่อสร้างลายเซ็นส่วนหนึ่งหรือผลลัพธ์ MPC ที่เกี่ยวข้อง
  • การตรวจสอบและรวมส่วนแบ่ง. ส่วนแบ่งที่ไม่ถูกต้องจะถูกปฏิเสธ ผู้ประสานงานหรือผู้เข้าร่วมทั้งหมดจะรวมส่วนแบ่งที่ถูกต้องเป็นลายเซ็นสุดท้ายหนึ่งเดียว
  • การตรวจสอบแบบปกติ บล็อกเชนหรือแอปพลิเคชันจะตรวจสอบลายเซ็นสุดท้ายภายใต้กุญแจสาธารณะของกลุ่มโดยใช้ตัวตรวจสอบปกติ ไม่จำเป็นต้องเข้าใจโปรโตคอลเกณฑ์ภายใน

ผู้ประสานงานเป็นบทบาทในโปรโตคอล ไม่ใช่ผู้ถือกุญแจที่เชื่อถือได้เสมอไป ใน FROST ตัวอย่างเช่น ผู้ประสานงานสามารถรวบรวมคำมั่นสัญญา เลือกชุดผู้ลงนาม แจกจ่ายข้อความ และรวมส่วนแบ่งได้โดยไม่ต้องรับส่วนแบ่งส่วนตัว ผู้ประสานงานยังคงสามารถก่อให้เกิดการปฏิเสธการให้บริการ ส่งมุมมองที่ไม่สอดคล้องกัน หรือนำเสนอข้อความที่เป็นอันตรายได้ ดังนั้น การสื่อสารที่ผ่านการตรวจสอบความถูกต้องและการตรวจสอบจากฝั่งผู้เข้าร่วมจึงยังคงจำเป็น

ทำไม nonces การประมวลผลล่วงหน้า และผู้ประสานงานจึงสำคัญ?

ตอบด่วน

การลงนามแบบเกณฑ์ (Threshold signing) สร้างสถานะโปรโตคอลที่เกี่ยวข้องกับข้อมูล nonce แบบใช้ครั้งเดียว (one-time nonce), ข้อผูกมัดของผู้เข้าร่วม และบันทึกการสนทนาที่แชร์ร่วมกัน การใช้ซ้ำหรือปรับแต่ง nonce, การผสมผสานเซสชัน, การยอมรับหลักฐานที่ผิดรูปแบบ หรือการให้ผู้เข้าร่วมลงนามในข้อความที่แตกต่างกัน อาจทำให้กุญแจกลุ่มถูกเปิดเผยหรือสร้างลายเซ็นที่ไม่ถูกต้อง การประมวลผลล่วงหน้าช่วยลดความล่าช้า แต่สร้างคลังข้อมูลก่อนลงนามที่มีค่า ซึ่งต้องได้รับการปกป้อง

Nonces เป็นส่วนหนึ่งของค่าลับ

การลงนาม Schnorr, EdDSA และ ECDSA ล้วนขึ้นอยู่กับค่าลับเฉพาะสำหรับแต่ละการลงนาม ซึ่งมักเรียกว่า nonce ในการลงนามแบบฝ่ายเดียวทั่วไป ไลบรารีที่เชื่อถือได้สามารถสร้างหรือหาค่า nonce ได้ภายในขอบเขตที่เชื่อถือได้หนึ่งเดียว แต่ในโปรโตคอลแบบ threshold หลายฝ่ายจะร่วมกันสร้างหรือคำนวณสถานะที่เกี่ยวข้องกับ nonce การใช้ nonce ซ้ำ การส่งคำมั่นสัญญาที่ถูกเล่นซ้ำ หรือข้อความการคูณที่ถูกทำให้ผิดรูปแบบโดยเจตนา สามารถทำให้การลงนามหนึ่งหรือหลายครั้งกลายเป็นการโจมตีเพื่อสกัดกุญแจได้ RFC 9591 เตือนอย่างชัดเจนว่า การอนุพันธ์ nonce แบบกำหนดค่าล่วงหน้า (deterministic) ที่เหมาะสมสำหรับ EdDSA ทั่วไปนั้นไม่ปลอดภัยในบริบทหลายฝ่าย และจำเป็นต้องสร้าง nonce ใหม่แบบสุ่มอย่างสม่ำเสมอ

ขั้นตอนการเตรียมข้อมูลล่วงหน้าจะดำเนินการก่อนที่ข้อความ

ระบบ threshold-ECDSA หลายระบบคำนวณข้อมูลที่กินทรัพยากรมากก่อนที่ธุรกรรมจะได้รับการยืนยัน ระยะออนไลน์จึงสามารถลดลงเหลือเพียงจำนวนข้อความที่น้อย ซึ่งมีความประโยชน์สำหรับผู้ลงนามแบบออฟไลน์และเครือข่ายที่มีความหน่วงสูง ข้อแลกเปลี่ยนคือด้านการปฏิบัติการ: ลายเซ็นล่วงหน้าจะกลายเป็นทรัพยากรการเข้ารหัสที่ใช้ได้เพียงครั้งเดียว การใช้ซ้ำ การย้อนกลับ การคัดลอกระหว่างสำเนา หรือการสูญเสียการซิงโครไนซ์สถานะอาจก่อให้เกิดผลร้ายแรง สำรองข้อมูลต้องไม่กู้คืนลายเซ็นล่วงหน้าที่ถูกใช้แล้วเหมือนว่ายังไม่เคยถูกใช้

การผูกมัดเซสชันป้องกันการโจมตีแบบ mix-and-match

ทุกข้อความควรถูกผูกมัดกับเวอร์ชันโปรโตคอล กุญแจสาธารณะของกลุ่ม ชุดผู้เข้าร่วม ดิจิสต์ข้อความ โซ่ เครือข่าย บทบาทผู้ลงนาม และเซสชันที่ไม่ซ้ำกัน ผู้เข้าร่วมควรปฏิเสธคำมั่นสัญญาที่ล้าสมัยหรือไม่สอดคล้อง และยืนยันว่าไบต์ของธุรกรรมสุดท้ายเป็นไบต์เดียวกันกับที่ได้รับการอนุญาตตามนโยบาย นี่คือจุดที่การออกแบบแอปพลิเคชันมาบรรจบกับวิทยาการเข้ารหัส: แกนการลงนามที่ปลอดภัยอย่างเป็นทางการอาจลงนามในโซ่ที่ผิด nonce ที่ผิด การเรียกสัญญาที่ผิด หรือปลายทางที่ผิดได้ หากตัวเชื่อมต่อส่งข้อมูลที่ผิด

ความทนทานไม่ได้เกิดขึ้นโดยอัตโนมัติ

โปรโตคอลบางตัวรับประกันความลับและความไม่สามารถปลอมแปลงได้ แต่จะยกเลิกกระบวนการเมื่อผู้เข้าร่วมหนึ่งคนมีพฤติกรรมผิดปกติ การยกเลิกที่สามารถระบุตัวได้สามารถชี้ชื่อผู้เข้าร่วมที่รับผิดชอบต่อความล้มเหลวได้ ส่วนความทนทานมีเป้าหมายที่จะดำเนินการให้เสร็จสิ้นแม้จะมีฝ่ายที่ไม่ดีอยู่บ้าง RFC 9591 ไม่รับประกันความทนทาน และระบุว่าตัวห่อระดับสูง เช่น ROAST สามารถจัดการกับการรบกวนที่มีเจตนาร้ายในบางสภาพแวดล้อมได้

FROST คืออะไร และ RFC 9591 มาตรฐานอะไร?

ตอบด่วน

FROST เป็นโปรโตคอล Schnorr แบบ threshold ที่สร้างลายเซ็นหลังจากสองรอบการสื่อสาร RFC 9591 กำหนดโปรโตคอลการลงนาม ชุดอัลกอริทึมการเข้ารหัส และเวกเตอร์ทดสอบ แต่ไม่ได้กำหนดมาตรฐานการสร้างกุญแจแบบกระจาย ความทนทาน การปกป้องเมตาดาต้า หรือรูปแบบการประมวลผลล่วงหน้าแบบหนึ่งรอบ และมันเป็น RFC วิจัย IRTF แบบให้ข้อมูลมากกว่าที่จะเป็นมาตรฐานอินเทอร์เน็ต

FROST ใช้ประโยชน์จากโครงสร้างเชิงเส้นของลายเซ็น Schnorr ผู้เข้าร่วมแต่ละคนที่ถูกเลือกจะถือส่วนแบ่งของกุญแจลงนามกลุ่ม ในรอบแรก ผู้เข้าร่วมจะสร้าง nonce แบบใช้ครั้งเดียวและเผยแพร่ commitment ในรอบที่สอง พวกเขาจะคำนวณส่วนแบ่งลายเซ็นที่ผูกกับข้อความ ชุดผู้ลงนาม และ commitment ผู้ประสานงานจะตรวจสอบและรวมส่วนแบ่งเหล่านั้นเพื่อสร้างลายเซ็น Schnorr สุดท้าย

RFC 9591 รวมถึงRFC 9591 เองไม่ได้ให้
โปรโตคอลการลงนาม FROST แบบสองรอบมาตรฐานการสร้างกุญแจแบบกระจายที่สมบูรณ์ชุดอัลกอริทึมการเข้ารหัสสำหรับ Ed25519, ristretto255, Ed448, P-256 และ secp256k1
ชุดอัลกอริทึมการเข้ารหัสสำหรับ Ed25519, ristretto255, Ed448, P-256 และ secp256k1.ความเข้ากันได้อัตโนมัติกับทุกโปรโตคอลที่ใช้เส้นโค้งเดียวกัน
ขั้นตอนการตรวจสอบและรวมส่วนแบ่งลายเซ็นขั้นตอนการตรวจสอบและรวมส่วนแบ่งลายเซ็นการดำเนินการที่มั่นคงแม้มีผู้เข้าร่วมที่มีเจตนาร้าย
การสร้างกุญแจแบบ Trusted-Dealer ในฐานะภาคผนวกที่ให้ข้อมูลเพิ่มเติมการรับประกันว่าไม่มีกุญแจที่สมบูรณ์อยู่ระหว่างขั้นตอนการตั้งค่า
ข้อพิจารณาด้านความปลอดภัยสำหรับการใช้ซ้ำ nonce ช่องทางข้างเคียง และการตรวจสอบความถูกต้องของข้อความความเป็นส่วนตัวของเมตาดาต้า การป้องกันการลดระดับความปลอดภัย หรือความปลอดภัยหลังยุคควอนตัม
เวกเตอร์ทดสอบสำหรับชุดทดสอบที่กำหนดการวิเคราะห์ธุรกรรมเฉพาะเชน นโยบาย หรือการกู้คืนกระเป๋าเงินการวิเคราะห์ธุรกรรมเฉพาะเชน นโยบาย หรือการกู้คืนกระเป๋าเงิน

การแยกแยะระหว่าง RFC ด้านการวิจัยกับมาตรฐานอินเทอร์เน็ตมีความสำคัญ RFC 9591 เป็นตัวแทนความเห็นพ้องของ Crypto Forum Research Group และให้ข้อกำหนดร่วมที่แม่นยำแก่ผู้พัฒนา แต่ในส่วนสถานะของมันระบุว่าเอกสารนี้มีวัตถุประสงค์เพื่อให้ข้อมูลเท่านั้น และไม่อยู่ในกระบวนการกำหนดมาตรฐานของ IETF NIST ได้เริ่มกระบวนการประเมินหลายปีสำหรับระบบ threshold แยกต่างหาก; FROST เป็นหนึ่งในระบบที่กำลังถูกพิจารณาสำหรับการประเมินดังกล่าว

ชุด RFC secp256k1 นี้เข้ากันได้กับ Bitcoin Taproot หรือไม่?

ไม่โดยอัตโนมัติ Bitcoin BIP340 กำหนดกุญแจสาธารณะแบบ x-only, ค่าแฮชที่มีแท็ก, สมการท้าทายเฉพาะ และรหัสเข้ารหัส 64 ไบต์ ชุดอัลกอริทึมการเข้ารหัส secp256k1 ของ FROST ใน RFC 9591 ใช้โครงสร้างแฮชที่แยกโดเมนและวิธีการจัดการจุดบีบอัดทั่วไป โปรโตคอลสามารถใช้เส้นโค้งเดียวกันได้ แต่ยังคงสร้างลายเซ็นที่ตัวตรวจสอบ BIP340 ปฏิเสธ ดังนั้น Schnorr แบบ threshold ที่เข้ากันได้กับ Bitcoin จึงจำเป็นต้องมีโครงสร้างและการนำไปใช้ที่ออกแบบมาอย่างชัดเจนเพื่อรองรับความหมายของ BIP340

ข้อสรุป: "ใช้ secp256k1" ไม่ใช่ใบรับรองความเข้ากันได้ เส้นโค้งเป็นเพียงชั้นหนึ่งของระบบลายเซ็นเท่านั้น

ทำไม ECDSA แบบ threshold จึงยากกว่า Schnorr แบบ threshold?

ตอบด่วน

ลายเซ็น Schnorr เป็นแบบเชิงเส้น ดังนั้นส่วนแบ่งลายเซ็นที่ได้รับการถ่วงน้ำหนักอย่างถูกต้องจึงสามารถรวมกันได้ ECDSA รวมถึงการคูณด้วยค่าผกผันของ nonce ลับ ซึ่งบังคับให้ฝ่ายต่างๆ ต้องคำนวณผลคูณและค่าผกผันของลับที่แบ่งปันกันโดยไม่เปิดเผยค่าเหล่านั้น ซึ่งต้องการกลไก MPC เพิ่มเติม การพิสูจน์ และรอบโปรโตคอล

ในรูปแบบที่เรียบง่าย ลายเซ็น ECDSA ประกอบด้วยค่า s = k^-1(H(m) + r x) mod q โดยที่ x คือกุญแจส่วนตัว และ k คือ nonce แบบใช้ครั้งเดียว ในบริบทของระบบเกณฑ์ (threshold setting), ทั้ง x และ k ไม่ควรถูกฝ่ายใดฝ่ายหนึ่งทราบ ดังนั้น ผู้เข้าร่วมต้องได้รับส่วนแบ่งแบบบวก (additive shares) หรือส่วนแบ่งแบบพหุนาม (polynomial shares) ของผลคูณที่เกี่ยวข้องกับ x และ k และในที่สุดของนิพจน์ที่เกี่ยวข้องกับค่าผกผัน (inverse-related expression) โดยต้องป้องกันไม่ให้ฝ่ายที่มีเจตนาร้ายเลือกค่าที่ผิดรูปแบบ (malformed values) ซึ่งอาจทำให้ส่วนแบ่งอื่นรั่วไหล

โปรโตคอลที่อิงตาม Paillier ใช้การเข้ารหัสแบบแอดดิทีฟโฮโมมอร์ฟิกและซับโปรโตคอลการแปลงการคูณเป็นการบวก (MtA) ส่วนตระกูลอื่น ๆ ใช้กลุ่มคลาสหรือการถ่ายโอนแบบไม่รู้ตัว การพิสูจน์แบบไม่เปิดเผยข้อมูล (Zero-knowledge proofs) หรือการตรวจสอบความสอดคล้อง (consistency checks) แสดงให้เห็นว่าค่าที่เข้ารหัสและส่วนแบ่งอยู่ในช่วงที่กำหนดและปฏิบัติตามความสัมพันธ์ของโปรโตคอล ส่วนประกอบเหล่านี้สร้างพื้นผิวการนำไปใช้ที่กว้างกว่า Schnorr แบบ threshold: การคำนวณจำนวนเต็มขนาดใหญ่ ระบบการพิสูจน์ การจัดการบันทึก การประมวลผลล่วงหน้า การระบุสาเหตุความล้มเหลว และสมมติฐานทางเข้ารหัสหลายประการ

มิติThreshold Schnorr / FROSTThreshold ECDSA
พีชคณิตหลักความสัมพันธ์เชิงเส้น; ส่วนแบ่งลายเซ็นสามารถรวมกันแบบบวกได้ความสัมพันธ์แบบไม่เชิงเส้นที่เกี่ยวข้องกับค่า nonce ร่วมกันแบบผกผันและผลคูณของข้อมูลลับ
การโต้ตอบการลงนามแบบทั่วไปสองรอบใน RFC 9591; มีรูปแบบการประมวลผลล่วงหน้าอื่นๆ นอกเหนือจาก RFCแตกต่างกันตามโปรโตคอล; การออกแบบแบบออนไลน์/ออฟไลน์สามารถทำให้ขั้นตอนออนไลน์สั้นลงได้
องค์ประกอบพื้นฐานเสริมกลุ่มลำดับแรก, ฮาช, การแบ่งปันความลับ, การให้คำมั่น และการตรวจสอบส่วนแบ่งอาจเพิ่มการเข้ารหัส Paillier หรือ class-group, การโอนแบบไม่รับรู้ (oblivious transfer), การพิสูจน์ช่วง (range proofs) และการตรวจสอบแบบไม่เปิดเผยข้อมูล (zero-knowledge checks)
ความซับซ้อนในการพัฒนาสูง แต่ค่อนข้างตรงไปตรงมามีความซับซ้อนสูงและในอดีตมีจุดเสี่ยงในการพัฒนาจำนวนมาก
ผลลัพธ์ของผู้ตรวจสอบลายเซ็น Schnorr ปกติหรือลายเซ็นที่เข้ากันได้กับชุดอัลกอริทึมที่เลือกลายเซ็น ECDSA ปกติ เมื่อกฎการเข้ารหัสเฉพาะของโซ่ถูกปฏิบัติตาม
ภาพรวมของโปรโตคอลFROST มีข้อกำหนด CFRG ที่ใช้ร่วมกันมีหลายตระกูลโปรโตคอล; ไม่มีมาตรฐานการปรับใช้สากลเดียว

Threshold ECDSA ยังคงมีความสำคัญ เนื่องจาก Bitcoin เวอร์ชันเก่าและการใช้จ่ายกุญแจ SegWit v0, บัญชี Ethereum ที่เป็นของบุคคลภายนอก และระบบอื่น ๆ ที่ถูกนำไปใช้งานจำนวนมากยังคงตรวจสอบ ECDSA ความเข้ากันได้กับที่อยู่และฮาร์ดแวร์ที่มีอยู่สามารถเป็นเหตุผลที่สนับสนุนความซับซ้อนนี้ แต่การเลือกควรทำด้วยความตระหนักอย่างชัดเจนถึงพื้นที่การโจมตีที่กว้างขึ้น

กลุ่มโปรโตคอล Threshold-ECDSA กลุ่มใดที่มีความสำคัญ?

ตอบด่วน

ภูมิทัศน์การนำไปใช้จริงและการวิจัยรวมถึงโปรโตคอล Paillier/MtA เช่น Gennaro-Goldfeder และ CGGMP, โปรโตคอลสองฝ่ายและหลายฝ่ายจาก Doerner-Kondi-Lee-Shelat, โครงสร้างแบบ class-group และแบบออกแบบใหม่ที่มีสองและสามรอบ ชื่อต่างๆ เช่น GG18, GG20 และ CGGMP21 ชี้ถึงบทความวิจัย ไม่ใช่มาตรฐานอุตสาหกรรมเดียวที่สามารถใช้แทนกันได้

สาขานี้พัฒนาอย่างรวดเร็ว และชื่อเรียกย่อของโปรโตคอลมักถูกใช้อย่างไม่แม่นยำ ผู้พัฒนาต้องระบุเวอร์ชันบทความที่ถูกต้อง ชุดพารามิเตอร์ การพิสูจน์ความปลอดภัย และเวอร์ชันโค้ดอย่างชัดเจน ไลบรารีที่อธิบายว่าเป็น "GG18" อาจรวมแพตช์ที่ออกภายหลัง ละเว้นการพิสูจน์ที่จำเป็น เพิ่มขั้นตอนการประมวลผลล่วงหน้าที่เป็นกรรมสิทธิ์ หรือใช้เวอร์ชันเก่าที่มีช่องโหว่ ปีที่ระบุในชื่อเรียกย่อไม่ใช่คำยืนยันความปลอดภัยที่เพียงพอ

โปรโตคอล / กลุ่มShapeข้อสำคัญหรือข้อควรระวัง
Lindell-Nof และ ECDSA สองฝ่ายที่เกี่ยวข้องออกแบบหลักเป็นแบบ 2-of-2การสร้างกุญแจและการลงนามแบบกระจายที่ใช้งานได้จริงสำหรับสองฝ่าย; มีสมมติฐานด้านความปลอดภัยและโครงสร้างที่แตกต่างกัน
GG18 / Gennaro-Goldfeder เวอร์ชันปรับปรุงECDSA แบบเกณฑ์ทั่วไปGG18 / Gennaro-Goldfeder ที่ปรับปรุงแล้วการตั้งค่าแบบไม่ต้องผ่านผู้จัดจำหน่ายที่รวดเร็วและการลงนามหลายฝ่ายที่ใช้งานได้จริงโดยใช้ Paillier/MtA; รายละเอียดการนำไปใช้และการปรับปรุงมีความสำคัญ
GG20ECDSA แบบ threshold ทั่วไปพร้อมการประมวลผลล่วงหน้าเพิ่มขั้นตอนออนไลน์แบบไม่โต้ตอบและฟังก์ชันยกเลิกที่สามารถระบุได้; การแก้ไขที่เผยแพร่ได้แก้ไขปัญหาต่างๆ แล้ว
CGGMP / CGGMP21จำนวนผู้ลงนามไม่จำกัด; การออกแบบเชิงรุกและเน้น UCGG20ECDSA แบบเกณฑ์ทั่วไปพร้อมการประมวลผลล่วงหน้าเพิ่มขั้นตอนออนไลน์แบบไม่โต้ตอบและการยกเลิกที่สามารถระบุได้; การแก้ไขที่เผยแพร่ได้แก้ไขปัญหาแล้วCGGMP / CGGMP21รวมการประมวลผลล่วงหน้า การรีเฟรชแบบเชิงรุก ความปลอดภัยแบบปรับตัวได้ และการยกเลิกที่สามารถระบุได้ ภายใต้สมมติฐานที่กำหนดไว้
ตระกูล DKLS สำหรับสองฝ่ายและหลายฝ่ายโปรโตคอล ECDSA ที่อิงตาม OT.หลีกเลี่ยงสมมติฐานของ Paillier ในโครงสร้างบางประเภท; งานวิจัยต่อมาเสนอการลงนามแบบสามรอบสำหรับกรณีที่มีกลุ่มส่วนใหญ่ไม่ซื่อสัตย์
โครงสร้างแบบกลุ่มคลาสและโครงสร้างใหม่กว่าเกณฑ์ต่าง ๆ และการแลกเปลี่ยนระหว่างออนไลน์/ออฟไลน์มุ่งปรับปรุงแบนด์วิดท์ จำนวนรอบ สมมติฐาน หรือความรับผิดชอบ; NIST กำลังรวบรวมผู้สมัครหลายราย

บทความนี้ไม่จัดอันดับโปรโตคอลเหล่านี้ ประสิทธิภาพขึ้นอยู่กับจำนวนผู้เข้าร่วม ภูมิศาสตร์ ค่าเกณฑ์ การประมวลผลล่วงหน้า ฮาร์ดแวร์ สมมติฐานเกี่ยวกับความพร้อมใช้งาน และคุณภาพการนำไปใช้ บทความที่ใหม่กว่าไม่ปลอดภัยโดยอัตโนมัติกว่าการนำไปใช้ที่พัฒนาแล้ว และการนำไปใช้ที่พัฒนาแล้วก็ไม่ปลอดภัยเพียงเพราะบทความพื้นฐานได้รับการศึกษาอย่างดี

FROST, MuSig2 และ multisig ทั่วไปมีความแตกต่างกันอย่างไร?

ตอบด่วน

FROST เป็นระบบ Schnorr แบบ threshold t-of-n ที่ใช้ส่วนแบ่งของกุญแจกลุ่มเดียว MuSig2 รวมกุญแจ Schnorr ที่อิสระหลายชุดและต้องการผู้ลงนามทั้ง n คน ดังนั้นจึงเป็นระบบ n-of-n ไม่ใช่ระบบ threshold ทั่วไป ส่วน multisig บนเชนแบบทั่วไปจะขอให้สคริปต์หรือสัญญาบนบล็อกเชนตรวจสอบกุญแจหรือลายเซ็นหลายชุดตามนโยบายของระบบเอง

คุณสมบัติFROSTMuSig2มัลติซิกบนเชน / กระเป๋าเงินสัญญา
โครงสร้างผู้ลงนามส่วนแบ่งของรหัสลับกลุ่มเดียวหลายกุญแจส่วนตัวที่สมบูรณ์และอิสระหลายกุญแจส่วนตัวที่สมบูรณ์และอิสระหลายกุญแจส่วนตัวที่สมบูรณ์ หรือสิทธิ์อื่น ๆ ที่กำหนดโดยสัญญา
Quorumt-of-n.n-of-n.m-of-n เฉพาะสำหรับเชน หรือนโยบายที่ปรับตั้งได้
ผู้ตรวจสอบจะเห็นลายเซ็นหนึ่งและกุญแจสาธารณะของกลุ่มหนึ่งหนึ่งลายเซ็น Schnorr รวมและหนึ่งกุญแจรวม.ลายเซ็นหลายรายการ การดำเนินการสคริปต์ หรือการเรียกสัญญา — เว้นแต่จะถูกซ่อนโดยการสร้างโครงสร้าง เช่น เส้นทางกุญแจ Taproot
การสร้างกุญแจDealer หรือ DKG / การตั้งค่าแบบกระจายการรวมกุญแจสาธารณะที่มีอยู่แบบไม่โต้ตอบผู้ลงนามแต่ละคนสร้างกุญแจธรรมดา; นโยบายถูกนำไปใช้บนเชน
การเปลี่ยนผู้เข้าร่วมอาจรักษาคีย์สาธารณะของกลุ่มไว้ได้ผ่านการแบ่งปันใหม่ หากระบบรองรับการเปลี่ยนผู้ลงนามจะเปลี่ยนกุญแจรวมการเปลี่ยนแปลงผู้ลงนามจะเปลี่ยนกุญแจรวมมักต้องการสคริปต์ใหม่ การอัปเดตสถานะสัญญา หรือที่อยู่ใหม่; การออกแบบอาจแตกต่างกัน
เอกสารอ้างอิงมาตรฐานหลักRFC 9591 สำหรับการลงนาม FROST สองรอบBIP327 สำหรับ MuSig2 ที่เข้ากันได้กับ BIP340.กฎสคริปต์ Bitcoin/Taproot, รหัสสัญญา Ethereum หรือกลไกเฉพาะของเชนอื่น ๆ

MuSig2 บางครั้งถูกเรียกว่าลายเซ็นแบบ threshold เนื่องจากมีหลายฝ่ายร่วมมือกัน BIP327 ระบุอย่างชัดเจนว่านี่เป็นระบบลายเซ็นหลายฝ่ายแบบ n-of-n ไม่ใช่ลายเซ็นแบบ threshold t-of-n ทุกกุญแจที่ใช้ในการรวมยังคงเป็นกุญแจลงนามที่สมบูรณ์ หากผู้เข้าร่วมหนึ่งคนไม่สามารถใช้งานได้ กลุ่มจะไม่สามารถลงนามได้ เว้นแต่จะมีเส้นทางสำรองแยกต่างหาก

Taproot ทำให้การเปรียบเทียบความโปร่งใสซับซ้อนขึ้น การใช้จ่ายผ่าน MuSig2 หรือเส้นทางกุญแจรวมอื่น ๆ อาจดูเหมือนการใช้จ่าย BIP340 แบบผู้ลงนามเดียวทั่วไป และเส้นทางสคริปต์ที่เป็นตัวเลือกจะยังคงถูกซ่อนไว้จนกว่าจะถูกใช้งาน การใช้จ่ายผ่านเส้นทางสคริปต์จะเปิดเผยสาขาที่ดำเนินการและหลักฐาน แต่ไม่จำเป็นต้องเปิดเผยทุกสาขาที่ไม่ได้ใช้งาน ดังนั้น คำกล่าวที่ว่า "มัลติซิกมองเห็นได้ ส่วน threshold มองไม่เห็น" จึงเป็นคำกล่าวที่เด็ดขาดเกินไป

การลงนามแบบ threshold เทียบกับการลงนามแบบ multisig บนเชน: ข้อแลกเปลี่ยนใดที่เปลี่ยนแปลง?

ตอบด่วน

Multisig บนเชนทำให้บล็อกเชนบังคับใช้ควอรัมโดยใช้กุญแจอิสระหรือตรรกะสัญญา Threshold signing บังคับใช้ควอรัมนอกเชนและแสดงกุญแจสาธารณะและลายเซ็นเดียวให้กับเชน Multisig มักเสนอนโยบายที่เรียบง่ายและตรวจสอบได้แบบอิสระ; ส่วน threshold signing เสนอลายเซ็นที่กะทัดรัด ความเป็นส่วนตัวของนโยบาย และความเป็นไปได้ในการรักษาความต่อเนื่องของที่อยู่ โดยแลกกับระบบเข้ารหัสที่ซับซ้อนมากขึ้นนอกเชน

การเปรียบเทียบนี้ไม่ใช่การจัดอันดับแบบสากล Bitcoin script, Taproot และบัญชีสัญญาอัจฉริยะของ Ethereum แสดงความสามารถที่แตกต่างกัน บางเชนสนับสนุนการลงนามหลายฝ่ายแบบเนทีฟที่มีประสิทธิภาพ ส่วนอื่น ๆ ต้องใช้กระเป๋าเงินสัญญา หรือขาดสคริปต์ที่ยืดหยุ่นโดยสิ้นเชิง การลงนามแบบ threshold signing สามารถทำให้เชนเห็นลายเซ็นที่คุ้นเคย แต่โปรโตคอลนอกเชนจะกลายเป็นส่วนหนึ่งของฐานการคำนวณที่เชื่อถือได้

มิติการลงนามหลายฝ่ายบนเชนการลงนามแบบเกณฑ์
ที่ข้อกำหนดจำนวนผู้ลงนามถูกบังคับใช้ตามกฎการตรวจสอบความถูกต้องของบล็อกเชนหรือรหัสสัญญาโดยโปรโตคอลการเข้ารหัสแบบนอกเชน
กุญแจผู้ลงนามแต่ละคนโดยปกติจะถือกุญแจอิสระที่สมบูรณ์ผู้เข้าร่วมแต่ละคนถือส่วนหนึ่งของกุญแจลงนามกลุ่มเดียว
ความสามารถในการตรวจสอบนโยบายและลายเซ็นอาจตรวจสอบได้บนเชน ขึ้นอยู่กับวิธีการสร้างผู้ตรวจสอบจะเห็นกุญแจหนึ่งชุดและลายเซ็นหนึ่งชุดเป็นปกติ; การยืนยันจำนวนเสียงภายใน (internal quorum) ไม่ได้รับการพิสูจน์บนเชน
ค่าธรรมเนียมและพื้นที่จัดเก็บอาจต้องการข้อมูลเพิ่มเติมหรือการดำเนินการสัญญา; การรวม Taproot สามารถลดสิ่งนี้ได้โดยทั่วไปจะมีลายเซ็นธรรมดาหนึ่งลายเซ็นที่ชั้นเชน
การแยกความล้มเหลวข้อผิดพลาดในผู้ลงนามหนึ่งคนไม่จำเป็นต้องทำให้กุญแจครบถ้วนของผู้ลงนามคนอื่นถูกเปิดเผยข้อบกพร่องในโปรโตคอลหรือการนำไปใช้บางครั้งอาจทำให้สามารถสกัดคีย์กลุ่มจากผู้เข้าร่วมที่ซื่อสัตย์ได้
ความต่อเนื่องของที่อยู่การเปลี่ยนแปลงนโยบายมักส่งผลให้สถานะของสคริปต์หรือสัญญาเปลี่ยนแปลงไปด้วย; การออกแบบอาจแตกต่างกันการแบ่งปันใหม่ของกลุ่มอาจรักษาคีย์สาธารณะของกลุ่มและที่อยู่เดิมไว้; โปรโตคอลหรือการดำเนินการบางประเภทอาจรักษาที่อยู่เดิมไว้ได้โปรโตคอลการแบ่งปันใหม่บางประเภทจะรักษาคีย์สาธารณะของกลุ่มและที่อยู่เดิมไว้
ความสามารถในการย้ายไปใช้ระบบอื่นขึ้นอยู่กับความสนับสนุนของสคริปต์หรือสัญญาบนเชนขึ้นอยู่กับความเข้ากันได้ของลายเซ็นอย่างแม่นยำ รวมถึงความถูกต้องของตัวปรับแต่งโซ่
การกู้คืนสามารถเข้ารหัสกุญแจสำรอง การหน่วงเวลา หรือการกำกับดูแลได้โดยตรงบนเชนขึ้นอยู่กับกระบวนการอัปเดต การแชร์ใหม่ การสำรองข้อมูล และการออกแบบบริการนอกเชน

การออกแบบที่มีประโยชน์อาจรวมทั้งสองวิธีเข้าด้วยกัน ตัวอย่างเช่น ผลลัพธ์ Taproot สามารถใช้เส้นทางกุญแจแบบรวม (aggregate) หรือแบบเกณฑ์ (threshold) สำหรับการใช้จ่ายตามปกติ และเก็บเส้นทางสคริปต์ที่ซ่อนไว้สำหรับการกู้คืนที่ล่าช้าตามเวลาหรือในกรณีฉุกเฉิน บัญชีอัจฉริยะของ Ethereum อาจต้องการลายเซ็น ECDSA ที่สร้างด้วยเกณฑ์ (threshold) พร้อมด้วยข้อจำกัดระดับสัญญา การจัดชั้น (layering) สามารถลดความเสี่ยงหนึ่งด้านได้ แต่เพิ่มความซับซ้อนในการดำเนินงาน ดังนั้นทุกสาขาการกู้คืนต้องได้รับการทดสอบอย่างจริงจัง ไม่ใช่เพียงการบันทึกไว้เท่านั้น

ลายเซ็นแบบ threshold ทำงานได้บนบล็อกเชนใดก็ได้หรือไม่?

ตอบด่วน

ไม่ โปรโตคอลแบบ threshold ต้องสร้างลายเซ็น รูปแบบกุญแจสาธารณะ และข้อความสรุป (message digest) ที่ตรงกับที่บล็อกเชนเป้าหมายตรวจสอบ ในบางกรณี การให้ตรงกับเส้นโค้งเอลลิปติกเป็นสิ่งจำเป็น แต่ไม่เพียงพอ การแฮช การเข้ารหัส การทำให้เป็นมาตรฐาน (canonicalisation) ตัวระบุการกู้คืน การสร้างที่อยู่ และเซมานติกส์ของธุรกรรมที่เฉพาะเจาะจงต่อบล็อกเชน ล้วนสามารถทำลายความเข้ากันได้

ชุดโครงสร้างลายเซ็นบล็อกเชนมีหลายชั้น: เส้นโค้งทางคณิตศาสตร์, สมการลายเซ็น, การเข้ารหัสกุญแจสาธารณะ, การเข้ารหัสลายเซ็น, การจัดลำดับธุรกรรม, การลงนามในค่าสรุป, การแยกโดเมน, กฎค่ามาตรฐาน และนิยามบัญชีหรือสคริปต์ การลงนามแบบเกณฑ์ต้องสอดคล้องกับทุกชั้นดังกล่าว คำว่า "ทำงานได้บนทุกบล็อกเชนที่มีเส้นโค้งเดียวกัน" ละเลยส่วนใหญ่ของชุดโครงสร้างนี้

ชั้นความเข้ากันได้ตัวอย่างที่แสดงให้เห็นว่าทำไมเรื่องนี้จึงสำคัญ
เส้นโค้งและกลุ่มsecp256k1, P-256 และ Ed25519 ใช้กลุ่มและวิธีการเข้ารหัสที่แตกต่างกัน
สมการลายเซ็นSchnorr แบบทั่วไปบน secp256k1 ไม่ถือเป็น Schnorr ตามมาตรฐาน BIP340 ของ Bitcoin โดยอัตโนมัติ
แฮชความท้าทาย / การแยกโดเมนR และกุญแจสาธารณะเดียวกันสามารถสร้าง challenge ที่ต่างกันได้ภายใต้กฎแฮชที่ต่างกัน
การเข้ารหัสลายเซ็นBitcoin BIP340 ใช้การเข้ารหัสแบบคงที่ 64 ไบต์; ระบบ ECDSA อาจใช้ DER, compact หรือ r/s พร้อมข้อมูลเมตาดาต้าสำหรับการกู้คืน
การทำให้เป็นมาตรฐานนโยบายของ Ethereum และ Bitcoin จำกัดลายเซ็น ECDSA ที่มีค่า s สูงด้วยวิธีต่าง ๆ; ตัวปรับค่าเกณฑ์ต้องให้ผลลัพธ์เป็นค่าที่ระบบยอมรับได้
การลงนามใน digestธง sighash ของ Bitcoin, ธุรกรรมแบบมีประเภทของ Ethereum และข้อความเฉพาะสัญญา จะลงนามในลำดับไบต์ที่แตกต่างกัน
การหาที่อยู่กุญแจสาธารณะเดียวกันอาจถูกแมปไปยังที่อยู่ต่างกันบนเชนหรือประเภทบัญชีที่ต่างกัน
นโยบายการใช้งานลายเซ็นที่ถูกต้องอาจยังคงอนุญาตให้ใช้กับเครือข่าย สัญญาโทเค็น nonce จำนวนเงิน หรือปลายทางที่ผิดได้

Bitcoin

การใช้กุญแจแบบ Legacy และ SegWit v0 ใช้ ECDSA ส่วนลายเซ็นเส้นทางกุญแจ Taproot ใช้ BIP340 Schnorr BIP340 มีกุญแจ x-only เฉพาะและกระบวนการแฮชที่มีแท็ก MuSig2 BIP327 ได้รับการออกแบบมาโดยเฉพาะสำหรับ BIP340 ไลบรารี threshold-ECDSA หรือ FROST แบบทั่วไปจำเป็นต้องมีตัวปรับแต่ง Bitcoin ที่จัดการการสร้าง sighash ประเภทสคริปต์ การปรับแต่งกุญแจ กฎ nonce และการเข้ารหัสลายเซ็นที่ยอมรับได้

Ethereum

บัญชีที่ถือครองโดยบุคคลภายนอกใช้ secp256k1 ECDSA และกู้คืนที่อยู่จากองค์ประกอบลายเซ็น ประเภทธุรกรรม Ethereum, ID โซ่ และข้อมูลโครงสร้างตาม EIP-712 ใช้โดเมนการลงนามที่แยกต่างหาก EIP-2 ปฏิเสธลายเซ็นธุรกรรมที่มีค่าสูง ดังนั้น ผู้ลงนามแบบ threshold จึงต้องสร้างค่า r และ s แบบมาตรฐาน พร้อมด้วยข้อมูลการกู้คืนที่ถูกต้องสำหรับ payload ที่เฉพาะเจาะจง

ระบบที่ใช้ Ed25519

RFC 9591 รวมถึงชุดเครื่องมือที่เข้ากันได้กับ Ed25519 และ Ed448 ซึ่งลายเซ็นสุดท้ายสามารถตรวจสอบได้โดยตัวตรวจสอบมาตรฐานที่สอดคล้องกัน อย่างไรก็ตาม แอปพลิเคชันยังคงต้องให้ข้อความเชนที่ถูกต้อง รูปแบบกุญแจสาธารณะ และนโยบายธุรกรรม ความเข้ากันได้ของตัวตรวจสอบไม่ยืนยันการบูรณาการกับกระเป๋าเงินโดยรอบ

การรีเฟรช การแบ่งปันใหม่ การกู้คืน และการเปลี่ยนแปลงสมาชิกภาพทำงานอย่างไร?

ตอบด่วน

การรีเฟรชแบบเชิงรุกจะแทนที่ทุกส่วนแบ่งด้วยส่วนแบ่งใหม่ที่มีคีย์ลับเดียวกัน โดยไม่เปลี่ยนแปลงคีย์สาธารณะของกลุ่ม การแชร์ใหม่ยังสามารถเปลี่ยนเกณฑ์หรือชุดผู้เข้าร่วมในโปรโตคอลที่ออกแบบมาเพื่อวัตถุประสงค์นี้ได้ ทั้งสองการดำเนินการนี้ไม่เกิดขึ้นโดยอัตโนมัติ: ต้องมีผู้เข้าร่วมที่ได้รับอนุญาตเพียงพอ การสื่อสารที่ผ่านการตรวจสอบความถูกต้อง สถานะที่ถูกต้อง และการสนับสนุนโปรโตคอลอย่างชัดเจน

การรีเฟรชเชิงรุก

การรีเฟรชจะเพิ่มการแชร์ที่มีค่าเป็นศูนย์ หรือจัดเรียงใหม่แบบสุ่มของส่วนแบ่งทั้งหมด เพื่อให้ความลับของกลุ่มที่อยู่เบื้องหลังยังคงเดิม ส่วนแบ่งเก่าควรไม่สามารถใช้งานได้หลังการรีเฟรช ภายใต้โมเดลความปลอดภัยเชิงรุก ผู้โจมตีที่เจาะระบบผู้เข้าร่วมต่าง ๆ ตามเวลาต้องรวบรวมส่วนแบ่งถึงเกณฑ์ภายในช่วงเวลาการรีเฟรชหนึ่งครั้ง แทนที่จะสะสมส่วนแบ่งไปเรื่อย ๆ การรีเฟรชไม่สามารถแก้ไขการเจาะระบบที่ถึงเกณฑ์แล้ว และไม่ลบสำเนาที่ผู้โจมตีอาจสร้างขึ้นจากข้อมูลรับรองของแอปพลิเคชันหรือระบบนโยบาย

การแบ่งปันใหม่และการเปลี่ยนผู้เข้าร่วม

โปรโตคอลการแบ่งปันใหม่สามารถแจกจ่ายส่วนแบ่งใหม่ไปยังกลุ่มผู้เข้าร่วมใหม่ และอาจเปลี่ยนแปลงค่า t หรือ n ในขณะที่ยังคงรักษากุญแจสาธารณะของกลุ่มไว้เหมือนเดิม สิ่งนี้สามารถใช้แทนอุปกรณ์ที่สูญหาย หมุนเวียนพนักงาน หรือปรับเปลี่ยนการควบคุมขององค์กรได้โดยไม่ต้องย้ายเงินบนเชน สิ่งนี้เป็นไปได้เฉพาะเมื่อโปรโตคอลรองรับและกลุ่มผู้ได้รับอนุญาตที่เพียงพอร่วมมือกัน ผลิตภัณฑ์ไม่สามารถ "สร้างใหม่" ส่วนแบ่งที่สูญหายจากศูนย์ได้

จะเกิดอะไรขึ้นเมื่อส่วนแบ่งหนึ่งสูญหาย?

หากยังมีส่วนแบ่งที่ถูกต้องอย่างน้อย t ส่วน กลุ่มสามารถดำเนินการลงนามต่อไปได้ตามปกติ และอาจสร้างส่วนแบ่งทดแทนได้ผ่านกระบวนการแบ่งปันใหม่ แต่หากส่วนแบ่งที่ยังเหลืออยู่มีน้อยกว่า t ส่วน และไม่มีกุญแจกู้คืนแยกต่างหาก สำรองข้อมูล หรือเส้นทางสัญญา อำนาจการลงนามจะสูญหายไป ระบบเกณฑ์ขั้นต่ำช่วยเพิ่มความซ้ำซ้อน แต่ไม่รับประกันการกู้คืนจากทุกรูปแบบการสูญเสีย

จะเกิดอะไรขึ้นเมื่อส่วนแบ่งหนึ่งถูกขโมย?

ในแบบจำลองการแบ่งปันความลับ t-of-n ที่สมบูรณ์แบบ หากมีหุ้นส่วนน้อยกว่า t จะไม่สามารถเปิดเผยความลับและไม่สามารถลงนามได้ ในทางปฏิบัติ หุ้นส่วนที่ถูกขโมยยังคงเป็นเหตุการณ์ความปลอดภัยที่ยังดำเนินอยู่ ผู้โจมตีอาจใช้มันในเซสชันโปรโตคอล ผสมผสานกับการละเมิดความปลอดภัยในอนาคต ใช้ประโยชน์จากข้อบกพร่องในการพัฒนา หรือเรียนรู้ข้อมูลเมตาดาต้า การตอบสนองที่ถูกต้องคือการหยุดเซสชันที่มีความเสี่ยง สืบสวน ปรับปรุงหรือแบ่งปันใหม่ หมุนเวียนข้อมูลรับรองที่เกี่ยวข้อง และตรวจสอบว่าผู้เข้าร่วมที่เหลือเป็นอิสระจากกัน

Six-scenario matrix for a 2-of-3 threshold design. It explains the consequences of one unavailable share, one stolen share, two compromised shares, a malicious coordinator, shares placed in one correlated cloud failure domain, and an implementation flaw. The diagram emphasises that thresholds depend on independence and code correctness.
รูป 3. การออกแบบแบบ 2-of-3 สามารถทนต่อการล้มเหลวของส่วนแบ่งหนึ่งส่วนที่แยกตัวได้; แต่โครงสร้างพื้นฐานที่มีความสัมพันธ์กันหรือข้อผิดพลาดในโปรโตคอลอาจทำให้เกณฑ์ขั้นต่ำที่กำหนดไว้ไม่สามารถทำงานได้

สมมติฐานด้านความปลอดภัยหลักและรูปแบบความล้มเหลวมีอะไรบ้าง?

ตอบด่วน

การลงนามด้วยเกณฑ์ (Threshold signing) ย้ายความเสี่ยงไปแทนที่จะกำจัดมันออกไป ประเภทความล้มเหลวหลัก ได้แก่ การถูกบุกรุกหลายส่วนเกินเกณฑ์ (threshold-many compromise), โครงสร้างพื้นฐานที่เชื่อมโยงกัน, ผู้เข้าร่วมที่มีเจตนาร้าย, การปฏิเสธการให้บริการ (denial of service), ความล้มเหลวของ nonce หรือความสุ่ม, ข้อบกพร่องในโปรโตคอลหรือการพิสูจน์, ช่องทางข้างเคียง (side channels), การบูรณาการโซ่ที่ไม่ถูกต้อง, การกู้คืนที่ไม่ปลอดภัย และชั้นนโยบายที่อนุญาตข้อความผิด

รูปแบบความล้มเหลวสิ่งที่อาจเกิดขึ้นการควบคุมหลัก
การละเมิดแบบ threshold-many shareผู้โจมตีสามารถสร้างลายเซ็นที่ถูกต้องได้ภายใต้กุญแจกลุ่มอุปกรณ์และผู้ดำเนินการที่อิสระ, การอัปเดต, หลักการสิทธิ์ขั้นต่ำ, การเฝ้าติดตาม และการหมุนเวียนอย่างรวดเร็ว
การละเมิดความปลอดภัยแบบเชื่อมโยงบัญชีผู้ใช้คลาวด์หนึ่งบัญชี ผู้ดูแลระบบ ช่องทางการอัปเดต หรือไลบรารีเดียวสามารถเข้าถึงหลายส่วนที่แชร์ได้แยกโดเมนความล้มเหลว ผู้จำหน่าย ข้อมูลรับรอง เครือข่าย และสิทธิ์การควบคุมการดำเนินงาน
ผู้เข้าร่วมที่มีเจตนาร้ายการยกเลิก, มุมมองที่ไม่สอดคล้องกัน, ข้อความโปรโตคอลที่ผิดรูปแบบ หรือการโจมตีแบบเลือกข้อมูลเข้าบันทึกการตรวจสอบความถูกต้องที่ผ่านการรับรอง, การตรวจสอบการแชร์, การยกเลิกที่สามารถระบุได้, ความทนทาน และขั้นตอนการยกเว้น
ความล้มเหลวของ nonce / presignatureการสกัดกุญแจอย่างสมบูรณ์หรือลายเซ็นที่ไม่ถูกต้องหลังการใช้งานซ้ำ, ความลำเอียง, การย้อนกลับ หรือการคัดลอก.CSPRNGs, สถานะใช้ครั้งเดียว, การจัดเก็บข้อมูลป้องกันการย้อนกลับ, การผูกมัดเซสชัน และการควบคุมสินค้าคงคลัง.
ข้อผิดพลาดในการนำโปรโตคอลไปใช้การสกัดกุญแจได้แม้โปรโตคอลระดับเอกสารจะปลอดภัยการนำไปใช้ตามเอกสารอย่างเคร่งครัด การตรวจสอบโดยผู้ตรวจสอบอิสระ เวกเตอร์ทดสอบ วิธีการทางรูปแบบเมื่อเป็นไปได้ และการบริหารจัดการการแก้ไขข้อบกพร่อง
ช่องข้างการรั่วไหลของข้อมูลแบ่งลับ (secret-share) หรือ nonce ผ่านพฤติกรรมด้านเวลา, แคช, พลังงาน, ความผิดพลาด หรือข้อผิดพลาดปริมิทีฟเวลาคงที่, การเสริมความปลอดภัย HSM/อุปกรณ์, การตรวจจับข้อผิดพลาด และการทดสอบเฉพาะสภาพแวดล้อม.
ข้อผิดพลาดในตัวปรับแต่งโซ่ลายเซ็นที่ถูกต้องบนข้อมูลที่ผิด, โซ่ที่ผิด หรือการเข้ารหัสที่ถูกปฏิเสธการวิเคราะห์ธุรกรรมแบบอิสระ, การเข้ารหัสแบบมาตรฐาน, เครือข่ายทดสอบ, เวกเตอร์อ้างอิง และการตรวจสอบความถูกต้องของนโยบาย.
ความล้มเหลวในการกู้คืนการล็อกเอาต์ถาวร การสร้างลับใหม่บนอุปกรณ์ที่ไม่ปลอดภัย หรือการใช้ "break-glass" โดยไม่ได้รับอนุญาตการกู้คืนที่บันทึกและฝึกซ้อมไว้แล้ว การแยกควอรัม ขั้นตอนที่ปิดผนึก และการติดตามตรวจสอบ
ความล้มเหลวของนโยบาย / ความผิดพลาดของมนุษย์ควอรัมลงนามในธุรกรรมหลอกลวง การอนุมัติที่มีเจตนาร้าย หรือธุรกรรมที่ตั้งค่าผิดพลาดหน้าจอแสดงข้อมูลที่เชื่อถือได้ชัดเจน การตรวจสอบอย่างอิสระ ขีดจำกัด รายการอนุญาต การหน่วงเวลา และการตรวจสอบนอกช่องทาง

ความปลอดภัยต่อการยกเลิกธุรกรรมแตกต่างจากความปลอดภัยต่อการโจรกรรม

โปรโตคอลหลายประเภทที่มีผู้เข้าร่วมส่วนใหญ่ไม่ซื่อสัตย์ยังคงรักษาความลับไว้ได้ แม้เมื่อผู้เข้าร่วมที่มีเจตนาร้ายหยุดเซสชัน นั่นถือเป็นผลลัพธ์ทางเข้ารหัสที่ประสบความสำเร็จ แต่เป็นผลลัพธ์ทางปฏิบัติการที่ล้มเหลว ระบบคลังเงินควรกำหนดว่าผู้เข้าร่วมที่ไม่ดีสามารถถูกตัดออกได้เร็วเพียงใด มีกลุ่มผู้ลงนามสำรองอยู่หรือไม่ เซสชันที่ล้าสมัยถูกยกเลิกอย่างไร และธุรกิจดำเนินต่อไปอย่างไรระหว่างการมีข้อพิพาท

ผู้ประสานงานสามารถไม่มีความลับแต่ยังคงมีอำนาจได้

ผู้ประสานงานอาจเลือกผู้ลงนาม รวบรวมคำมั่นสัญญา เลือกข้อความ กำหนดเวลาเซสชัน และเผยแพร่ลายเซ็นสุดท้าย แม้ไม่มีส่วนแบ่งกุญแจ ผู้ประสานงานก็ยังสามารถสังเกตข้อมูลเมตาเซ็นเซอร์คำขอ แบ่งมุมมองของผู้เข้าร่วม หรือกระตุ้นงานที่มีค่าใช้จ่ายสูงซ้ำๆ ได้ ข้อความในโปรโตคอลควรได้รับการยืนยันตัวตน ผู้เข้าร่วมควรสร้างหรือตรวจสอบธุรกรรมอย่างอิสระ และการเฝ้าระวังควรแยกความล้มเหลวปกติออกจากพฤติกรรมที่เป็นปฏิปักษ์

การลงนามแบบเกณฑ์ (Threshold signing) ไม่ได้รับการออกแบบให้ทนต่อคอมพิวเตอร์ควอนตัมโดยค่าเริ่มต้น

FROST, ECDSA และระบบ Schnorr ปัจจุบันพึ่งพาสมมติฐานเกี่ยวกับลอการิทึมแบบไม่ต่อเนื่อง การแบ่งกุญแจไม่ทำให้อัลกอริทึมการลงนามพื้นฐานทนทานต่อคอมพิวเตอร์ควอนตัมที่มีความสามารถเพียงพอ ลายเซ็นเกณฑ์หลังยุคควอนตัมเป็นพื้นที่วิจัยและมาตรฐานที่กำลังพัฒนาอยู่ และการวางแผนการย้ายระบบต้องพิจารณาทั้งตัวตรวจสอบเชนและชั้นการจัดการกุญแจแบบกระจาย

Alpha-Rays, TSSHOCK และงานวิจัยการสกัดกุญแจในภายหลังได้แสดงให้เห็นอะไร?

ตอบด่วน

การวิจัยเหล่านี้แสดงให้เห็นว่า การใช้ทางลัดในการพัฒนา ECDSA แบบ threshold สามารถทำให้ผู้เข้าร่วมที่มีเจตนาร้ายสกัดกุญแจลงนามได้ครบถ้วน โดยไม่ต้องทำลาย ECDSA หรือเส้นโค้งเอลลิปติก การขาดหลักฐานช่วง (range proofs), พารามิเตอร์ Paillier ที่ผิดรูปแบบ, การตรวจสอบแบบ zero-knowledge ที่อ่อนแอ และข้อผิดพลาดในการเขียนโค้ดที่เฉพาะเจาะจงกับโปรโตคอล ได้เปลี่ยนการเข้าถึงแบบ sub-threshold ให้กลายเป็นการละเมิดระบบอย่างสมบูรณ์

Alpha-Rays

การวิจัย Alpha-Rays ปี 2021 ได้อธิบายการโจมตีเพื่อสกัดคีย์ต่อการใช้งาน ECDSA แบบเกณฑ์ GG18 และ GG20 การโจมตีเหล่านี้มุ่งเป้าไปที่โปรโตคอลย่อยการคูณเพื่อบวก (multiplication-to-addition) และตัวเลือกการดำเนินการ เช่น โหมด "เร็ว" (fast) ที่ไม่มีหลักฐานช่วง (range proofs) ที่จำเป็น ผู้เข้าร่วมที่มีเจตนาร้ายสามารถใช้ประโยชน์จากปฏิสัมพันธ์นี้เพื่อกู้คืนคีย์ทั้งหมดได้ ผลลัพธ์นี้ไม่ได้ทำให้ ECDSA ถูกทำลาย แต่แสดงให้เห็นว่าการละเว้นขั้นตอนการพิสูจน์และการตรวจสอบจะทำให้ข้อโต้แย้งด้านความปลอดภัยเป็นโมฆะ

TSSHOCK

TSSHOCK ซึ่งถูกเปิดเผยในปี 2023 ได้บันทึกการโจมตีเพิ่มเติมต่อระบบการนำ ECDSA แบบ threshold ไปใช้งาน การวิจัยนี้มุ่งเน้นไปที่ข้อบกพร่องในการนำเข้ารหัสแบบ homomorphic และการจัดการหลักฐาน และแสดงให้เห็นหลายวิธีในการกู้คืนกุญแจส่วนตัว บทเรียนสำคัญนี้มีความกว้างขวางกว่าการโจมตีที่กล่าวถึง: โปรโตคอล ECDSA แบบ threshold มีความไวต่อช่วงค่าที่แม่นยำ การตรวจสอบพารามิเตอร์ ข้อความหลักฐาน และการจัดการข้อผิดพลาด

BitGo Zero Proof

ช่องโหว่ของกระเป๋าเงิน BitGo ที่เปิดเผยต่อสาธารณะ ซึ่งถูกค้นพบโดย Fireblocks ได้แสดงให้เห็นรูปแบบเดียวกันในระบบที่ใช้งานจริง การขาดการตรวจสอบความถูกต้องของหลักฐานในกระบวนการ ECDSA แบบสองฝ่าย อาจทำให้ฝ่ายหนึ่งสามารถสกัดส่วนแบ่งของอีกฝ่ายและสร้างกุญแจใหม่ได้ บริการที่ได้รับผลกระทบถูกระงับและแก้ไขหลังจากมีการเปิดเผยอีกครั้ง ความล้มเหลวนี้ไม่ได้เกิดจากองค์ประกอบพื้นฐานของ ECDSA แต่เกิดจากการนำโปรโตคอลไปใช้งานและการขาดขอบเขตการตรวจสอบ

การวิจัยการสกัดกุญแจในทางปฏิบัติในปี 2024

การวิจัยทางวิชาการและอุตสาหกรรมในเวลาต่อมาได้วิเคราะห์การนำระบบกระเป๋าเงิน MPC ชั้นนำไปใช้ และรายงานการโจมตีเพื่อสกัดกุญแจที่ต้องการจำนวนการโต้ตอบการลงนามที่แตกต่างกัน โดยในบางกรณีต้องการเพียงการลงนามเพียงครั้งเดียวภายใต้เงื่อนไขที่ศึกษา ผลลัพธ์เหล่านี้เน้นย้ำถึงความจำเป็นในการระบุเวอร์ชันโปรโตคอลที่แม่นยำ รวมถึงทุกขั้นตอนการพิสูจน์และการตรวจสอบ และถือว่าการทบทวนการนำระบบไปใช้เป็นส่วนหนึ่งของคำกล่าวอ้างด้านความปลอดภัยทางเข้ารหัส

ควรประเมินการนำไปใช้ MPC หรือลายเซ็นแบบเกณฑ์อย่างไร?

ตอบด่วน

เริ่มต้นด้วยโปรโตคอล เวอร์ชัน และโมเดลผู้โจมตีที่ถูกต้อง จากนั้นประเมินโค้ด ความสุ่ม วงจรชีวิตของ nonce ช่องทาง ความต้านทานต่อช่องข้าง อะแดปเตอร์โซ่ ความเป็นอิสระของส่วนแบ่ง การรีเฟรช การกู้คืน และนโยบาย "ใช้ MPC", "ผ่านการตรวจสอบ" หรือ "กุญแจไม่เคยมีอยู่" ไม่เพียงพอที่จะเป็นหลักฐานได้ด้วยตัวเอง

ข้อกำหนดทางเข้ารหัส

  • ระบุชื่อบทความฉบับเต็ม ฉบับแก้ไข ชุดอัลกอริทึมการเข้ารหัส และชุดพารามิเตอร์ให้ชัดเจน ยืนยันว่าการนำไปใช้งานตรงกับเวอร์ชันที่มีการอ้างอิงหลักฐานการตรวจสอบหรือไม่
  • บันทึกค่าเกณฑ์ (threshold), จำนวนผู้เข้าร่วม, แบบการทุจริตแบบคงที่หรือแบบปรับตัวได้, สมมติฐานเกี่ยวกับกลุ่มส่วนใหญ่ที่ซื่อสัตย์หรือไม่ซื่อสัตย์, พฤติกรรมการยกเลิก (abort behavior) และคำกล่าวอ้างเกี่ยวกับความทนทาน (robustness claims)
  • ยืนยันวิธีการสร้างหรือนำเข้ากุญแจ ว่ามีผู้จัดจำหน่ายที่เชื่อถือได้หรือไม่ และว่ามีการสร้างกุญแจที่สมบูรณ์หรือข้อมูลสำรองที่สามารถสร้างใหม่ได้หรือไม่
  • ระบุทุกองค์ประกอบพื้นฐานเสริม: พารามิเตอร์ Paillier, การโอนแบบไม่รับรู้ (oblivious transfer), กลุ่มคลาส (class groups), การให้คำมั่น (commitments), หลักฐานความรู้เป็นศูนย์ (zero-knowledge proofs), ฟังก์ชันแฮช (hash functions) และตัวสร้างตัวเลขสุ่ม (random-number generators)

การนำไปใช้และการทดสอบ

  • ต้องมีการตรวจสอบอย่างอิสระโดยผู้เชี่ยวชาญในตระกูลโปรโตคอลเฉพาะนั้น ไม่ใช่เพียงการตรวจสอบสัญญาอัจฉริยะหรือแอปพลิเคชันทั่วไป
  • ทดสอบทุกเส้นทางเชิงลบ: จุดที่ผิดรูปแบบ, สเกลาร์, หลักฐาน, ข้อความเข้ารหัส, ตัวระบุผู้เข้าร่วม, ชุดผู้ลงนาม, nonce ที่ซ้ำกัน, ข้อความที่ถูกเล่นซ้ำ และเซสชันที่ถูกยกเลิก
  • ใช้ปริมิทีฟที่ใช้เวลาคงที่และต้านทานช่องข้างที่เหมาะสมกับสภาพแวดล้อมของอุปกรณ์; ปกป้องบันทึก, ข้อมูลการหยุดทำงาน, พื้นที่สวอป, ระบบเทเลเมทรี และระบบการสังเกตการณ์
  • ตรวจสอบความถูกต้องเทียบกับเวกเตอร์ทดสอบที่เผยแพร่แล้ว และสร้างการทดสอบความสามารถในการทำงานร่วมกันระหว่างการนำไปใช้ต่าง ๆ เมื่อมีข้อกำหนด
  • รักษากระบวนการตอบสนองต่อจุดอ่อนที่สามารถเพิกถอนสิทธิ์ของผู้เข้าร่วม หยุดการลงนาม อัปเดตการแบ่งปัน และโอนเงินได้ โดยไม่ซ่อนผลกระทบต่อการดำเนินงาน

สถาปัตยกรรมปฏิบัติการ

  • จัดวางส่วนแบ่งในโดเมนความล้มเหลวที่อิสระอย่างแท้จริง: ข้อมูลรับรอง ผู้ดูแลระบบ อุปกรณ์ เครือข่ายที่แตกต่างกัน และหากเป็นไปได้ ควรใช้รากซอฟต์แวร์หรือฮาร์ดแวร์ที่แตกต่างกันเมื่อเหมาะสม
  • ปกป้องสถานะก่อนการลงนามและ nonce จากการย้อนกลับ (rollback), การคัดลอก (cloning) และการกู้คืนจากข้อมูลสำรอง (backup restoration) ให้ถือว่าสถานะที่ถูกใช้แล้วเป็นสถานะที่ถูกใช้ไปอย่างถาวร
  • ตรวจสอบความถูกต้องของข้อความจากผู้เข้าร่วม และให้ข้อมูลธุรกรรมที่เพียงพอแก่ผู้ลงนามแต่ละคนเพื่อตรวจสอบความถูกต้องของกิจกรรมทางเศรษฐกิจ ไม่ใช่เพียงค่าแฮชที่ไม่มีบริบท
  • ฝึกซ้อมการรับมือกับการสูญเสียข้อมูล การถูกละเมิดความปลอดภัย การลาออกของพนักงาน การหยุดทำงานของระบบคลาวด์ การล้มเหลวของผู้ประสานงาน และการกู้คืนหลังภัยพิบัติ แผนการกู้คืนที่ยังไม่เคยถูกนำไปปฏิบัติจริงนั้นเป็นเพียงสมมติฐานเท่านั้น
  • ติดตามการพยายามลงนาม การเลือกผู้เข้าร่วม การพิสูจน์ที่ล้มเหลว เหตุการณ์การอัปเดต และการแทนที่นโยบาย ความเป็นส่วนตัวทางเข้ารหัสไม่ควรทำให้ความรับผิดชอบในการดำเนินงานหายไป
ธงแดงทำไมจึงไม่เพียงพอหรืออันตราย
"MPC ระดับทหาร" ที่ไม่มีชื่อโปรโตคอลไม่มีข้ออ้างทางเทคนิคใดที่จะประเมินได้
ทุกส่วนแบ่งทำงานภายใต้ผู้เช่าคลาวด์เดียวกันเกณฑ์ขั้นต่ำอาจพังทลายได้หากข้อมูลรับรองหรือผู้ดูแลระบบถูกละเมิดเพียงครั้งเดียว
การกู้คืนสามารถสร้างส่วนแบ่งใด ๆ ขึ้นใหม่ได้โดยไม่ต้องมีควอรัมอาจมีรหัสลับหลักที่ซ่อนอยู่ หรือหน่วยงานกู้คืนข้อมูลส่วนกลางอาจมีรหัสลับหลักที่ซ่อนอยู่ หรือหน่วยงานกู้คืนข้อมูลส่วนกลาง
ไลบรารี secp256k1 แบบทั่วไปถูกกล่าวถึงว่าสนับสนุนทุกเชนความเข้ากันได้ของ Curve ไม่คำนึงถึงความแตกต่างของข้อความ การเข้ารหัส และตัวตรวจสอบรายงานการตรวจสอบครอบคลุมเฉพาะแอปพลิเคชันมือถือหรือสัญญาอัจฉริยะเท่านั้น
รายงานการตรวจสอบครอบคลุมเฉพาะแอปมือถือหรือสัญญาอัจฉริยะเท่านั้นโปรโตคอลเกณฑ์ขั้นต่ำ การเข้ารหัสแบบเนทีฟ และสถานะแบ็กเอนด์ อาจยังไม่ได้รับการตรวจสอบ
ไม่มีเอกสารบันทึกการตอบสนองต่อส่วนที่ถูกขโมยระบบอาจขาดฟังก์ชันการอัปเดต การแบ่งปันใหม่ หรือการย้ายข้อมูลในสถานการณ์ฉุกเฉิน
ผู้ลงนามได้รับเพียงค่าสรุปที่ไม่โปร่งใสพวกเขาไม่สามารถตรวจสอบด้วยตนเองได้ว่าพวกเขากำลังอนุมัติการดำเนินการทางเศรษฐกิจใด

คำถามที่มักถูกถาม

MPC เหมือนกับลายเซ็นแบบ threshold หรือไม่?

ไม่ MPC เป็นสาขาวิชาที่กว้างขวางเกี่ยวกับการคำนวณบนข้อมูลส่วนตัวที่ถือครองโดยหลายฝ่าย การลงนามแบบ threshold เป็นหนึ่งในแอปพลิเคชันของ MPC ที่สร้างลายเซ็นดิจิทัลภายใต้กุญแจกลุ่มที่ใช้ร่วมกัน แอปพลิเคชัน MPC อื่น ๆ ได้แก่ การถอดรหัสแบบ threshold การตัดกันของชุดข้อมูลส่วนตัว และการสร้างค่าสุ่มร่วมกัน

กระเป๋าเงินแบบ threshold มีกุญแจส่วนตัวหรือไม่?

มันมีอำนาจลงนามที่สอดคล้องกับกุญแจสาธารณะ แต่อำนาจนั้นอาจมีอยู่เพียงในรูปแบบของส่วนแบ่งที่กระจายไปเท่านั้น ในออกแบบที่ใช้ DKG (Distributed Key Generation) ผู้เข้าร่วมใด ๆ ก็ไม่เคยถือกุญแจส่วนตัวครบถ้วนเลย ส่วนในออกแบบแบบดีลเลอร์ (Dealer), อิมพอร์ต (Import) หรือรีคอนสตรัคชัน (Reconstruction) กุญแจครบถ้วนอาจมีอยู่ในบางขั้นตอน

ส่วนแบ่งที่ถูกขโมยไปหนึ่งส่วนสามารถขโมยเงินได้หรือไม่?

ภายใต้ระบบ t-of-n ที่ถูกนำไปใช้อย่างถูกต้อง ส่วนแบ่งน้อยกว่า t ไม่ควรสร้างลายเซ็นหรือเปิดเผยกุญแจได้ การถูกขโมยส่วนแบ่งหนึ่งยังคงเป็นเหตุการณ์ที่อาจเกิดขึ้นได้: ผู้โจมตีอาจรวมมันกับการถูกบุกรุกในภายหลัง ใช้ประโยชน์จากเซสชันโปรโตคอล หรือหาช่องโหว่ในกระบวนการนำไปใช้ ให้ทำการรีเฟรชหรือแบ่งส่วนใหม่เมื่อการออกแบบอนุญาต

ส่วนที่ถูกสูญเสียสามารถแทนที่ได้หรือไม่?

ได้ก็ต่อเมื่อยังมีส่วนแบ่งที่ได้รับอนุญาตเหลืออยู่เพียงพอ และโปรโตคอลหรือสถาปัตยกรรมการกู้คืนสนับสนุนการแบ่งปันใหม่ ผู้เข้าร่วมที่ยังเหลืออยู่บางครั้งสามารถสร้างส่วนแบ่งใหม่ได้ โดยยังคงรักษาคีย์สาธารณะไว้ หากจำนวนส่วนแบ่งที่ยังเหลืออยู่ต่ำกว่าเกณฑ์ที่กำหนด และไม่มีเส้นทางการกู้คืนแยกต่างหาก คีย์จะไม่สามารถกู้คืนได้

FROST เป็นมาตรฐานอินเทอร์เน็ตอย่างเป็นทางการหรือไม่?

ไม่ RFC 9591 เป็นเอกสารข้อมูลของ IRTF ที่แสดงถึงฉันทามติของ Crypto Forum Research Group มันเป็นข้อกำหนดการแบ่งปันที่แม่นยำ แต่ไม่ใช่เอกสารมาตรฐานของ IETF NIST กำลังประเมินข้อเสนอเกี่ยวกับระบบเกณฑ์ (threshold-scheme) แยกต่างหากผ่านกระบวนการที่เริ่มการเรียกอย่างเป็นทางการในปี 2026

RFC 9591 มีกระบวนการสร้างกุญแจหรือไม่?

ข้อกำหนดหลักครอบคลุมการลงนาม FROST สองรอบ การสร้างกุญแจอยู่นอกขอบเขตหลักอย่างชัดเจน ส่วนภาคผนวกให้ตัวอย่างของผู้จำหน่ายที่เชื่อถือได้ (trusted dealer) และระบบที่นำไปใช้งานสามารถใช้โปรโตคอล DKG แยกต่างหากได้

FROST secp256k1 เข้ากันได้กับ Bitcoin Taproot หรือไม่?

RFC นี้รวมถึงชุดอัลกอริทึมการเข้ารหัส secp256k1 แต่สิ่งนี้ไม่ได้ทำให้มันเข้ากันได้กับ BIP340 โดยอัตโนมัติ Bitcoin ใช้กุญแจ x-only เฉพาะเจาะจง, ค่าแฮชที่มีแท็ก และกฎการเข้ารหัส การใช้งาน Bitcoin จำเป็นต้องมีโครงสร้างเกณฑ์เฉพาะตาม BIP340 และตัวปรับแต่งโซ่

MuSig2 เป็นลายเซ็นแบบ threshold หรือไม่?

MuSig2 เป็นระบบลายเซ็นหลายฝ่ายที่รวมกุญแจ Schnorr ที่อิสระกัน และต้องการผู้ลงนามทั้ง n คน BIP327 อธิบายอย่างชัดเจนว่าเป็นระบบ n-of-n แทนที่จะเป็นระบบลายเซ็นแบบ threshold t-of-n ทั่วไป

บล็อกเชนสามารถระบุได้หรือไม่ว่ามีการใช้ MPC?

โดยทั่วไปแล้วไม่สามารถระบุได้จากลายเซ็นสุดท้ายเพียงอย่างเดียว: มันถูกตรวจสอบเหมือนลายเซ็นทั่วไปภายใต้กุญแจสาธารณะเดียว ประเภทที่อยู่ รหัสสัญญา รูปแบบธุรกรรม ข้อมูลเมตาของบริการ หรือการเปิดเผยข้อมูลในภายหลัง อาจยังคงเปิดเผยการออกแบบการเก็บรักษาได้ Taproot ยังสามารถซ่อนนโยบายลายเซ็นหลายฝ่ายและสคริปต์บางส่วนได้ ดังนั้นการซ่อนตัวจึงไม่ใช่คุณสมบัติเฉพาะของ MPC

การลงนามแบบ threshold ปลอดภัยกว่าการลงนามหลายลายเซ็นหรือไม่?

ไม่มีวิธีใดที่ปลอดภัยกว่าอย่างทั่วถึง มัลติซิก (Multisig) ให้นโยบายที่บังคับใช้บนเชนอย่างเรียบง่ายและกุญแจสมบูรณ์ที่แยกกัน; การลงนามแบบ threshold สามารถลดรอยเท้าบนเชน ซ่อนจำนวนผู้ลงนามขั้นต่ำ และรักษาที่อยู่ผ่านการแบ่งปันใหม่ได้ โปรโตคอล threshold เพิ่มความซับซ้อนทางเข้ารหัสและการนำไปใช้แบบนอกเชน การเลือกที่ถูกต้องขึ้นอยู่กับเชน โมเดลภัยคุกคาม ความต้องการในการกู้คืน และทักษะการดำเนินงาน

การลงนามแบบ threshold ช่วยป้องกันการหลอกลวงได้หรือไม่?

มันอาจต้องการการอนุมัติหลายครั้งและบังคับใช้ข้อจำกัด แต่ควอรัมที่ถูกต้องตามกฎหมายยังสามารถลงนามในธุรกรรมที่เป็นอันตรายได้ ผู้เข้าร่วมและระบบนโยบายต้องเข้าใจจุดหมายปลายทาง จำนวนเงิน การเรียกใช้สัญญา เครือข่าย และสิทธิ์อย่างแม่นยำก่อนที่จะสร้างส่วนแบ่ง

การเข้ารหัสแบบเกณฑ์ (Threshold cryptography) เป็นแบบหลังควอนตัมหรือไม่?

ระบบเกณฑ์ปัจจุบันอย่าง FROST, Schnorr และ ECDSA ยังไม่รองรับยุคหลังควอนตัม (post-quantum) ระบบเหล่านี้กระจายอำนาจการลงนามที่มีอยู่ แต่ยังคงยึดถือสมมติฐานด้านความปลอดภัยของอัลกอริทึมการลงนามพื้นฐาน ระบบเกณฑ์ยุคหลังควอนตัมต้องการองค์ประกอบพื้นฐานที่แตกต่างและการสนับสนุนจากเครือข่ายบล็อกเชน

สรุป

การเข้ารหัสแบบเกณฑ์ (Threshold cryptography) แก้ปัญหาการดำเนินงานที่แท้จริง: ลับการลงนามเพียงหนึ่งเดียวไม่ควรกำหนดชะตากรรมของยอดเงินจำนวนมาก ระบบ หรือสถาบัน การแก้ปัญหาไม่ใช่เพียงการแบ่งกุญแจออกเป็นชิ้นๆ การออกแบบลายเซ็นแบบเกณฑ์ที่สมบูรณ์ต้องกำหนดวิธีการสร้างส่วนแบ่ง วิธีการปกป้องความสุ่มแบบครั้งเดียว วิธีการที่ผู้เข้าร่วมตกลงกันเกี่ยวกับข้อความเดียว วิธีการปฏิเสธส่วนร่วมที่มีรูปแบบผิดปกติ วิธีการกำหนดความรับผิดชอบเมื่อเกิดความล้มเหลว วิธีการอัปเดตส่วนแบ่ง และวิธีการที่ลายเซ็นสุดท้ายตรงกับโซ่เป้าหมาย

การแก้ไขที่สำคัญที่สุดต่อภาษาการตลาดทั่วไปคือว่าทุกคำกล่าวอ้างล้วนมีเงื่อนไข ระบบที่ใช้ DKG สามารถหลีกเลี่ยงการใช้กุญแจเต็มรูปแบบตลอดอายุการใช้งานได้ ส่วนระบบที่ใช้กุญแจนำเข้าไม่สามารถอ้างถึงประวัติการใช้งานแบบเดียวกันได้ ส่วนแบ่งเดียวอาจไม่เพียงพอทางเข้ารหัสลับแต่มีความเร่งด่วนในการดำเนินงาน ลายเซ็นเดียวอาจดูธรรมดาบนเชน แต่กลับพึ่งพาฐานการคำนวณที่เชื่อถือได้ขนาดใหญ่แบบออฟเชน โปรโตคอลหนึ่งอาจได้รับการพิสูจน์ว่าปลอดภัย แต่ถูกนำไปใช้งานอย่างไม่ปลอดภัย

เมื่อใช้ร่วมกับโดเมนความล้มเหลวที่แยกกัน, โค้ดที่ผ่านการตรวจสอบ, การปฏิบัติตามกฎ nonce อย่างเคร่งครัด, อะแดปเตอร์เชนที่ถูกต้อง, กระบวนการกู้คืนที่ผ่านการฝึกซ้อม และผู้ลงนามที่ตรวจสอบสิ่งที่พวกเขาอนุมัติ การลงนามแบบ threshold สามารถขจัดจุดล้มเหลวเดียวได้โดยไม่สูญเสียความเข้ากันได้กับการตรวจสอบลายเซ็นแบบปกติ แต่หากใช้เพียงเป็นป้ายกำกับโดยไม่มีมาตรการควบคุมเหล่านี้ มันอาจปกปิดจุดล้มเหลวเดียวที่ซับซ้อนยิ่งขึ้น

แหล่งข้อมูลและข้อมูลเพิ่มเติม

เอกสารอ้างอิงหลักสำหรับบทความนี้ อัปเดต ณ เดือนกรกฎาคม 2026

แบบทดสอบด่วน: มันติดไหม?

คำถามสองสามข้อเพื่อตรวจสอบพื้นฐานที่มาถึง คำตอบพร้อมคำอธิบายจะตามมา และไม่มีใครให้คะแนนคุณนอกจากผลงานในอนาคตของคุณ

คำถาม 1/6
ความแตกต่างระหว่าง Shamir backup และ threshold signing คืออะไร?

ข้อมูลนี้มีประโยชน์ไหม