วิวัฒนาการของอัลกอริทึม Bitcoin ไปสู่อัลกอริทึมลายเซ็นของ Schnorr มีความคืบหน้าหรือไม่? |
วงล้อแห่งประวัติศาสตร์กำลังหมุนไปข้างหน้าและความก้าวหน้าของเทคโนโลยีไม่เคยหยุดนิ่ง โปรโตคอล Bitcoin ก้าวสำคัญได้เริ่มการอัปเกรดเทคโนโลยีแล้ว การอัพเกรดทางเทคนิคในโปรโตคอล Schnorr Signature (Schnorr Signature) และ Taproot (Taproot of the tree) ได้รวมเข้ากับ Bitcoin Core เวอร์ชัน 0.21.0 แล้ว
อนาคตของ Bitcoin ดูสดใสกว่าที่เคย และตอนนี้มีโอกาสที่จะเหนือกว่าบล็อคเชนอื่น ๆ ทั้งหมด ไม่เพียงแต่ด้วยความจุเท่านั้น แต่ยังรวมถึงฟังก์ชันการทำงานด้วย
เมื่อใช้อัลกอริทึมลายเซ็นโค้งวงรี Bitcoin ECDSA กระบวนการตรวจสอบธุรกรรมหลายลายเซ็นนั้นยุ่งยากมาก ตอนนี้ เป็นไปได้ที่จะรวมลายเซ็นและคีย์สาธารณะทั้งหมดในการทำธุรกรรมเป็นลายเซ็นเดียวและคีย์สาธารณะ จะเกิดอะไรขึ้นถ้า ไม่สามารถติดตามได้และง่ายและรวดเร็ว?
จริงๆ แล้วก่อนหน้านี้ ตอนที่ Satoshi Nakamoto ออกแบบโปรโตคอล Bitcoin เขาจำเป็นต้องพิจารณาเงื่อนไขต่างๆ เช่น ความยาวของลายเซ็นของอัลกอริทึมลายเซ็น ไม่ว่าจะเป็นโอเพ่นซอร์ส มีสิทธิบัตรหรือไม่ ผ่านการตรวจสอบความปลอดภัยมานาน เวลาและประสิทธิภาพที่เพียงพอ ในเวลานั้น ไม่เพียงแต่อัลกอริธึมลายเซ็นดิจิทัล ECDSA เท่านั้นที่ตรงตามเงื่อนไขข้างต้น แต่ยังมี Schnorr Signature ซึ่งเป็นอัลกอริทึมลายเซ็นดิจิทัลที่ไม่ต่ำกว่า ECDSA ในทุกด้าน อย่างไรก็ตาม เนื่องจากมันอยู่ในสถานะการคุ้มครองสิทธิบัตรก่อนปี 2008 นี่อาจเป็นเหตุผลว่าทำไม Satoshi Nakamoto ไม่ได้ใช้อัลกอริทึมลายเซ็นนี้เมื่อออกแบบโปรโตคอล Bitcoin และในที่สุดก็เลือกอัลกอริทึมลายเซ็นดิจิตอล Elliptic Curve (ECDSA) วงรีพิเศษ เลือกเส้นโค้ง secp256k1 ตามคำแนะนำของ
หลังจากผ่านไป 10 ปี ในเดือนกรกฎาคม 2018 Pieter Wuille ผู้พัฒนา Bitcoin ได้เขียน bip-schnorr และเสนอให้เปลี่ยนอัลกอริทึมลายเซ็นของ bitcoin เป็น schnorr แม้ว่า Schnorr และ ECDSA จะเป็นอัลกอริทึมการเข้ารหัสแบบเส้นโค้งวงรีโดยใช้เส้นโค้ง secp236k1 แต่เนื่องจากข้อได้เปรียบของ Schnorr Signature ในลักษณะการเข้ารหัส จึงสะดวกกว่าในการสร้างธุรกรรมแบบหลายลายเซ็นบนพื้นฐานของการรักษาความปลอดภัยที่เกือบจะเหมือนกัน
Schnorr ที่ใช้กับ Bitcoin มีข้อดีที่สำคัญเพิ่มเติมเหนือ ECDSA:
ปลอดภัยกว่า: เป็นเรื่องง่ายที่จะพิสูจน์ความปลอดภัยของลายเซ็น Schnorr ในแบบจำลอง oracle แบบสุ่ม แต่ไม่มีหลักฐานดังกล่าวสำหรับ ECDSA
ไม่มีปัญหาความอ่อนตัว: ลายเซ็น ECDSA เป็นแบบอ่อนได้ บุคคลที่สามสามารถแก้ไขลายเซ็นที่มีอยู่ได้โดยตรงโดยไม่ต้องรู้รหัสส่วนตัว และยังคงรักษาลายเซ็นที่ถูกต้องสำหรับธุรกรรมนี้ มีการโจมตี Bitcoin อยู่เสมอ ซึ่งไม่ได้รับการแก้ไขจนกว่าจะมีการเปิดใช้งาน SegWit โดยมีเงื่อนไขว่าการทำธุรกรรม segwit จะถูกใช้แทนการทำธุรกรรมแบบดั้งเดิม BIP62 และ BIP66 อธิบายรายละเอียดนี้
เชิงเส้น: อัลกอริทึมลายเซ็น Schnorr เป็นแบบเชิงเส้น! จากคุณลักษณะนี้ สามารถสร้างระบบบล็อกเชนที่มีประสิทธิภาพและเป็นส่วนตัวมากขึ้นได้ ฝ่ายที่ใช้ลายเซ็น Schnorr สามารถสร้างการรวมลายเซ็นของคีย์ที่เกี่ยวข้องได้ ตัวอย่างเช่น หากใช้คีย์สาธารณะ N รายการในการเซ็นชื่อ หากใช้ ECDSA จะมีลายเซ็น N รายการ และการตรวจสอบจะต้องทำ N ครั้งด้วย หากใช้ Schnorr เนื่องจากคุณสมบัติเชิงเส้น การซ้อนทับลายเซ็นสามารถทำได้ และจะเก็บเฉพาะลายเซ็นซ้อนสุดท้ายเท่านั้น ตัวอย่างเช่น โดยไม่คำนึงถึงจำนวนอินพุตในธุรกรรมเดียวกัน ก็สามารถซ้อนทับเป็นลายเซ็นเดียวได้ และการยืนยันเพียงครั้งเดียวก็เพียงพอแล้ว
อัลกอริธึมลายเซ็นของ Schnorr เหนือกว่าอัลกอริธึมลายเซ็น ECDSA ที่มีอยู่ของ Bitcoin ในเกือบทุกด้าน: ประสิทธิภาพ ความปลอดภัย ปริมาณ ความสามารถในการปรับขนาด ฯลฯ และ Schnorr Sig สามารถใช้เส้นโค้งวงรีเดียวกันกับ ECDSA: เส้นโค้ง secp256k1 ซึ่งเป็นการเปลี่ยนแปลงที่อัปเกรดเล็กน้อยมาก
Q&A
ถาม: สามารถใช้ลายเซ็น Schnorr สำหรับลายเซ็นหลายรายการจำนวน n รายการได้หรือไม่
ตอบ: แน่นอนคุณทำได้ Multisig เป็นเพียงรูปแบบของ m ของจำนวนลายเซ็น โดยไม่คำนึงถึงอัลกอริทึมลายเซ็น
ถาม: ฟีเจอร์ลายเซ็นกลุ่มของ Schnorr สามารถสร้างหรือจำลองลายเซ็นจำนวน n รายการได้หรือไม่
ตอบ: ไม่สามารถทำได้ หากมีคีย์สาธารณะ N รายการในกลุ่ม จะต้องมีลายเซ็น N อันที่สอดคล้องกัน ซึ่งทั้งหมดนี้จะขาดไม่ได้ เมื่อทุกคนสร้างลายเซ็น ทุกคนจะแทนที่คีย์สาธารณะกลุ่ม P ในฟังก์ชันแฮช
ถาม: จะวัดความปลอดภัยของกลไกลายเซ็นได้อย่างไร
ตอบ: ส่วนใหญ่ขึ้นอยู่กับสองอย่าง: 1. อัลกอริทึมลายเซ็นเอง 2. เส้นโค้งวงรี ปัจจุบัน ทั้ง Schnorr และ ECDSA ใช้เส้นโค้ง secp256k1 ซึ่งเป็นระดับเดียวกัน สำหรับความปลอดภัยของอัลกอริทึมลายเซ็นนั้น ปัจจุบัน Schnorr มีใบรับรองความปลอดภัยซึ่งดีกว่า ECDSA
การทดลองใช้อัลกอริทึม Schnorr Signature ของ BCH
ตั้งแต่วันที่ 16 พฤษภาคม 2019 BCH ได้เริ่มอัปเกรดฮาร์ดฟอร์กแล้ว เนื้อหาหลักของการอัปเกรดคืออัลกอริทึมลายเซ็นของ Schnorr และการกู้คืน Segregated Witness ซึ่งเป็นฟังก์ชันที่ได้รับการคาดหวังมากที่สุดในการอัปเกรดลายเซ็นของ Schnorr และหลักการกู้คืน Segregated Witness คือเทคโนโลยีการซ่อมแซมเพื่อดึง BCH ที่ส่งไปยังที่อยู่ Segregated Witness อย่างไม่ถูกต้อง
นักพัฒนา Mark Lundeberg ผู้ใช้ไม่จำเป็นต้องสร้างที่อยู่ใหม่เพื่อเริ่มใช้ลายเซ็นของ Schnorr ข้อดีของ BCH จากการอัปเกรดนี้มีดังนี้:
1. ปรับปรุงความถูกต้องของข้อมูลลายเซ็น: เนื่องจากลายเซ็นมีข้อมูล 64 ไบต์ เมื่อเทียบกับปกติ 70 ไบต์ การทำธุรกรรมจึงสามารถลดจำนวนไบต์ลงได้ 4% ความถูกต้องของข้อมูลลายเซ็น (ลายเซ็น Schnorr จะลดการจัดเก็บบล็อกเชน และแบนด์วิธอย่างน้อย 25% ทำให้เครือข่าย BCH เร็วขึ้นและมีประสิทธิภาพมากขึ้น) และหลังจากการอัปเกรด ลายเซ็น Schnorr ทำให้ BCH สามารถซ่อนช่องทางการชำระเงินทั่วไปได้
2. การปรับปรุงความเป็นส่วนตัว: ก่อนการอัปเกรด ผู้ใช้จำนวนมากจงใจใช้ลายเซ็นหลายรายการในการส่งธุรกรรมเพื่อปรับปรุงความเป็นส่วนตัว และลายเซ็นของ Schnorr จะทำให้ลายเซ็นของผู้ใช้ทั้งหมดดูเหมือนกับลายเซ็นอื่นๆ โครงสร้างนี้นำไปสู่การเพิ่มความเป็นส่วนตัวในการทำธุรกรรมในเรื่องเพศอย่างมีนัยสำคัญ คุณสมบัติที่ให้บริการโดย Schnorr และส่วนขยายบางส่วนที่เพิ่มโดยนักพัฒนา BCH และผู้ให้บริการโครงสร้างพื้นฐาน เช่น กระเป๋าเงิน จะเพิ่มความเป็นส่วนตัวและความสามารถในการปรับขนาด
3. ต่อสู้กับการโจมตีธุรกรรมสแปม: มีการโจมตีธุรกรรมสแปมในอดีต ผู้โจมตีหวังว่าจะทำให้ Bitcoin แออัดผ่านพื้นที่ธุรกรรมมากที่สุดเท่าที่จะเป็นไปได้ วิธีหนึ่งของพวกเขาคือทำให้ธุรกรรมนี้เกิดขึ้นโดยส่งธุรกรรมจากหลายแหล่งบ่อยๆ การทำธุรกรรมประกอบด้วยลายเซ็นจำนวนมากซึ่งใช้พื้นที่มาก นี่คืออันตรายที่ซ่อนอยู่จากลายเซ็น ECDSA Schnorr สามารถหลีกเลี่ยงการโจมตีจากสแปมดังกล่าวได้ หากธุรกรรมแต่ละรายการมีลายเซ็นเดียว บล็อกสามารถรองรับธุรกรรมได้มากขึ้น และผู้ส่งสแปมต้องส่งธุรกรรมมากขึ้นหากต้องการสร้างการโจมตีและแข่งขันกับผู้คนมากขึ้น ดังนั้นค่าใช้จ่ายในการโจมตีจะค่อนข้างสูง พื้นที่ที่ใช้โดยลายเซ็นมักจะเป็นส่วนที่ใหญ่ที่สุดของธุรกรรม ดังนั้นผู้โจมตีจึงไม่ได้เปรียบ
แน่นอน เราไม่สามารถมองเห็นแต่ด้านดี ทุกอย่างจะขาดหายไป และสุดขั้วจะกลับด้าน โดยเฉพาะอย่างยิ่งการพัฒนาควอนตัมคอมพิวเตอร์ได้กระตุ้นให้ผู้มีวิสัยทัศน์บางคนค้นหาวิธีแก้ไขโดยเร็วที่สุด ทั้งนี้ เพื่อจัดการกับการโจมตีของคอมพิวเตอร์ควอนตัมในบางอัลกอริทึม ในปี 2560 NIST ได้เริ่มกระบวนการกำหนดมาตรฐานการเข้ารหัสหลังควอนตัม - ส่งเสริมรูปแบบลายเซ็นควอนตัม ซึ่งเป็นหนึ่งในอัลกอริธึมต่อต้านควอนตัมที่สนับสนุนโดยรากฐานการเข้ารหัสหลังควอนตัม และรูปแบบลายเซ็นต่อต้านควอนตัมลายเซ็นที่มีความยาวลายเซ็นสั้นที่สุด - ลายเซ็นสายรุ้งมีแนวโน้มดีที่สุด
ในเดือนสิงหาคม 2017 Jin Liu และนักคณิตศาสตร์ Prof. Jintai Ding เตรียมก่อตั้ง ABCMint และจดทะเบียนใน Encryption Valley ใกล้เมืองซูริก ประเทศสวิตเซอร์แลนด์ ลายเซ็นพื้นฐานของสกุลเงินดิจิทัล ABC คือลายเซ็นสีรุ้ง Rainbow วิสัยทัศน์ของพวกเขาคือการสนับสนุนการวิจัยและการประยุกต์ใช้อัลกอริทึมการถอดรหัสคอมพิวเตอร์ควอนตัมทั่วโลก การวิจัยรวมถึงการสนับสนุนนักคณิตศาสตร์ในการค้นพบ ถอดรหัส และปรับปรุงอัลกอริทึมทั่วโลก อัลกอริทึมถูกนำไปใช้กับการเข้ารหัสลับดิจิทัลหลัก
พวกเขาเชื่อว่าข้อเสนอ BIP340 ของ Bitcoin ซึ่งใช้ลายเซ็น Schnorr จาก ECDSA ไปจนถึงลายเซ็น Schnorr เป็นการถดถอยครั้งใหญ่ของ Bitcoin เราไม่มองในแง่ดีเกี่ยวกับการเลือกอัลกอริทึมและการปรับปรุงที่เสนอโดยผู้เชี่ยวชาญด้านความปลอดภัยของคอมพิวเตอร์ เราชอบการเลือกและการปรับปรุงอัลกอริทึมที่เสนอโดยนักคณิตศาสตร์ ลายเซ็น Schnorr มีปัญหาใหญ่ และควรใช้ใน Litecoin และอื่น ๆ ที่คล้ายกันสำหรับการทดสอบเป็นเวลานาน วิ่ง.
พูดง่ายๆ ก็คือ การกระจายอำนาจนั้นเบี่ยงเบนไปจากหลายลายเซ็น
ต่อไปนี้เป็นอัลกอริทึมง่ายๆ:
1 อัลกอริทึมลายเซ็นดิจิทัล Elliptic Curve (ECDSA)
อัลกอริทึมลายเซ็นดิจิทัล Elliptic Curve (ECDSA, อัลกอริทึมลายเซ็นดิจิทัล Elliptic Curve) เป็นการจำลองอัลกอริทึมลายเซ็นดิจิทัล (DSA) โดยใช้ Elliptic Curve Cryptography (ECC) (Elliptic Curve Cryptography (ECC) คิดค้นโดย Neal Koblitz และ Victor Miller ในปี 1985) ECDSA ถูกเสนอครั้งแรกโดย Scott และ Vanstone ในปี 1992 เพื่อตอบสนองต่อคำขอของ NIST สำหรับ Digital Signature Standard (DSS)
ปัจจุบัน Bitcoin ใช้อัลกอริธึมลายเซ็นดิจิทัล ECDSA elliptic curve ในการเซ็นข้อความ m เราจำเป็นต้องแฮชและถือว่าแฮชนี้เป็นตัวเลข: z = hash(m) นอกจากนี้เรายังต้องการหมายเลขการค้นหาแบบสุ่มหรือสุ่ม k เราไม่ชอบเชื่อถือตัวสร้างตัวเลขสุ่ม (มีบั๊กมากเกินไป มีบั๊กมากมายที่เกี่ยวข้องกับ RGN ที่ไม่ดี) ดังนั้นเราจึงมักจะใช้ RFC6979 และคำนวณค่า K ที่กำหนดขึ้นจากความลับของเราและข้อความที่เราต้องการเซ็นชื่อ
การใช้คีย์ส่วนตัว pk เราสามารถสร้างลายเซ็นสำหรับข้อความ m ซึ่งประกอบด้วยตัวเลขสองตัว: r (พิกัด x ของจุดสุ่ม R = k×G) และ s = (z+r⋅pk)/k จากนั้น ใช้รหัสสาธารณะของเรา P = pk×G ทุกคนสามารถตรวจสอบลายเซ็นของเราได้โดยตรวจสอบว่าพิกัด x ของจุด (z/s)×G+(r/s)×P เท่ากับ r
การตรวจสอบลายเซ็นรวมถึงการผกผัน (1/วินาที) และการคูณสองจุด และการดำเนินการเหล่านี้มีค่าใช้จ่ายสูงในการคำนวณ ใน Bitcoin ทุกโหนดต้องตรวจสอบธุรกรรมทั้งหมด ซึ่งหมายความว่าเมื่อคุณถ่ายทอดธุรกรรม คอมพิวเตอร์หลายพันเครื่องจะต้องตรวจสอบลายเซ็นของคุณ และการทำให้กระบวนการตรวจสอบง่ายขึ้นจะเป็นประโยชน์อย่างมาก แม้ว่าขั้นตอนการเซ็นชื่อจะยากขึ้นก็ตาม
ประการที่สอง แต่ละโหนดต้องตรวจสอบแต่ละลายเซ็นแยกกัน หากเป็นโหนดการทำธุรกรรมหลายลายเซ็น m-of-n อาจจำเป็นต้องตรวจสอบลายเซ็นเดียวกันหลายครั้ง ตัวอย่างเช่น ธุรกรรมที่มีอินพุต multisig แบบ 7 จาก 11 จะมี 7 ลายเซ็น และต้องมีการยืนยันลายเซ็น 7-11 สำหรับทุก ๆ โหนดในเครือข่าย นอกจากนี้ ธุรกรรมดังกล่าวใช้พื้นที่มากและคุณต้องจ่ายเงินเป็นจำนวนมาก
ลายเซ็น Schnorr
อัลกอริทึมลายเซ็น Schnorr เสนอโดยนักคณิตศาสตร์ชาวเยอรมันและนักวิทยาการเข้ารหัสลับ Claus Schnorr และได้ยื่นขอรับสิทธิบัตรในปี พ.ศ. 2533 US Patent 4,995,082 ซึ่งหมดอายุในเดือนกุมภาพันธ์ พ.ศ. 2551 ขณะนี้อัลกอริทึมมีให้ใช้งานฟรี
ลายเซ็นของ Schnorr นั้นแตกต่างกันเล็กน้อย เราใช้จุด R และสเกลาร์ s แทนสเกลาร์สองตัว (r, s) เช่นเดียวกับ ECDSA R คือจุดสุ่มบนเส้นโค้งวงรี (R=K×G) ส่วนที่สองของลายเซ็นคำนวณแตกต่างกันเล็กน้อย:
s = k + hash(P,R,m) ⋅ pk ที่นี่ pk คือคีย์ส่วนตัวของคุณ และ P = pk×G คือคีย์สาธารณะของคุณ และ m คือข้อความ ลายเซ็นนี้สามารถตรวจสอบได้โดยการตรวจสอบ s×G = R + hash(P,R,m)×P
สมการนี้เป็นแบบเชิงเส้น ดังนั้นสมการจึงสามารถบวกและลบออกจากกันได้และยังคงใช้ได้ ซึ่งให้ประโยชน์มากมายเกี่ยวกับลายเซ็นของ Schnorr
3 การตรวจสอบชุดของลายเซ็น Schnorr
ในการตรวจสอบบล็อกใน Bitcoin blockchain เราจำเป็นต้องตรวจสอบให้แน่ใจว่าลายเซ็นทั้งหมดในบล็อกนั้นถูกต้อง
สำหรับอัลกอริทึมลายเซ็น ECDSA แต่ละลายเซ็นจะต้องได้รับการตรวจสอบทีละรายการ นั่นคือหากมี 1,000 ลายเซ็นในบล็อก เราจำเป็นต้องคำนวณ 1,000 การผกผันและการคูณ 2,000 จุด สำหรับงานคำนวณหนักทั้งหมดประมาณ 3,000 งาน
และด้วยการใช้ลายเซ็น Schnorr เราสามารถรวมสมการการตรวจสอบลายเซ็นทั้งหมดได้ ซึ่งช่วยประหยัดพลังงานในการคำนวณ สำหรับบล็อกที่มี 1,000 ลายเซ็น เราจำเป็นต้องตรวจสอบ:
(s1+s2+…+s1000)×G=(R1+…+R1000)+(hash(P1,R1,m1)×P1+hash(P2,R2,m2)×P2+…+hash(P1000,R1000,m1000)×P1000)
ที่นี่เรามีการเพิ่มจำนวนมาก (เกือบจะฟรีในพลังการคำนวณ) และการคูณ 1,001 จุด เราจำเป็นต้องคำนวณการคำนวณอย่างหนักประมาณหนึ่งรายการสำหรับแต่ละลายเซ็น
4 การรวมคีย์สำหรับลายเซ็น Schnorr
เราต้องการรักษาบิตคอยน์ของเราให้ปลอดภัย ดังนั้นเราอาจต้องการใช้คีย์ส่วนตัวที่แตกต่างกันอย่างน้อย 2 อันเพื่อควบคุมบิตคอยน์ของเรา ตัวอย่างเช่น หนึ่งรายการบนแล็ปท็อปหรือโทรศัพท์มือถือ และอีกรายการหนึ่งบนฮาร์ดแวร์กระเป๋าเงิน/กระเป๋าเงินเย็น ดังนั้นเมื่อหนึ่งในนั้นถูกบุกรุก เรายังคงสามารถควบคุมบิตคอยน์ของเราได้
ปัจจุบันดำเนินการผ่านสคริปต์แบบหลายลายเซ็นแบบ 2 ใน 2 ซึ่งต้องมีลายเซ็นแยกกัน 2 ลายเซ็นในการทำธุรกรรม ในขณะที่ลายเซ็น schnorr เราสามารถใช้คีย์ส่วนตัวคู่หนึ่ง (pk1,pk2) และสร้างลายเซ็นที่ใช้ร่วมกันซึ่งสอดคล้องกับคีย์สาธารณะที่ใช้ร่วมกัน P=P1+P2=pk1×G+pk2×G ในการสร้างลายเซ็นนี้ เราจำเป็นต้องเลือกหมายเลขสุ่ม (k1,k2) บนอุปกรณ์แต่ละเครื่อง สร้างจุดสุ่ม Ri=ki×G เพิ่มเพื่อคำนวณแฮชสาธารณะ (P,R1+R2,m) จากนั้น รับ s1 และ s2 จากแต่ละอุปกรณ์ (si = ki + hash(P,R,m) ⋅ pki) จากนั้นเราสามารถรวมลายเซ็นเหล่านี้และใช้คู่ (R, s) = (R1+R2, s1+s2) เป็นลายเซ็นของเราบนคีย์สาธารณะที่ใช้ร่วมกัน p คนอื่นไม่สามารถบอกได้ว่าเป็นลายเซ็นรวมหรือไม่ แต่ดูเหมือนลายเซ็น schnorr ทั่วไปทุกประการ
มีปัญหา 3 ประการเกี่ยวกับโครงสร้างนี้ ประการแรก จากมุมมองของส่วนต่อประสานผู้ใช้ ในการทำธุรกรรม เราจำเป็นต้องสื่อสารหลายรอบ คำนวณ R สาธารณะ จากนั้นจึง - ลงชื่อ ด้วยคีย์ส่วนตัวสองคีย์ สิ่งนี้สามารถทำได้ด้วยการเข้าถึงกระเป๋าเงินเย็นเพียงครั้งเดียว: เราเตรียมธุรกรรมที่ไม่ได้ลงนามในกระเป๋าเงินออนไลน์ เลือก k1 และเขียน R1=K1×G พร้อมกับธุรกรรมที่ไม่ได้ลงนาม จากนั้นเราจะถ่ายโอนข้อมูลนี้ไปยังกระเป๋าเงินเย็นและลงนาม เนื่องจากเรามี R1 อยู่แล้ว เราจึงสามารถเซ็นธุรกรรมในกระเป๋าเงินเย็นได้ในครั้งเดียว จากกระเป๋าเงินเย็น เราได้รับ R2 และ s2 และโอนกลับไปยังกระเป๋าเงินออนไลน์ กระเป๋าเงินออนไลน์ลงนามธุรกรรมด้วยตัวเลือกที่เลือกไว้ก่อนหน้านี้ (k1, R1) รวมลายเซ็นและเผยแพร่ธุรกรรมที่ลงนาม สิ่งนี้คล้ายกับที่เราอยู่ตอนนี้มาก แต่เมื่อคุณเพิ่มคีย์ส่วนตัวที่สาม ทุกอย่างจะซับซ้อนมากขึ้น สมมติว่าคุณมีโชค ซึ่งถูกควบคุมโดยคีย์ส่วนตัว 10 อัน ซึ่งเก็บไว้ในตำแหน่งที่ปลอดภัยที่แตกต่างกันทั่วโลก จากนั้น คุณต้องทำธุรกรรม ในปัจจุบัน คุณต้องผ่านตำแหน่งเหล่านี้ทั้งหมดเพียงครั้งเดียว แต่หากคุณใช้การรวมคีย์ คุณต้องทำสองครั้ง เพื่อรวบรวม RI ทั้งหมด จากนั้นลงชื่อ ในกรณีนี้ เป็นการดีกว่าที่จะเก็บลายเซ็นส่วนบุคคลไว้โดยไม่มีการรวมเข้าด้วยกัน ดังนั้นเราจำเป็นต้องมีการสื่อสาร 3 รอบ:
เลือกตัวเลขสุ่ม ki และ Ri=ki×G ที่สอดคล้องกัน และบอกทุกคนเฉพาะแฮช ti=hash(Ri) เพื่อให้ทุกคนมั่นใจได้ว่าคุณจะไม่เปลี่ยนใจหลังจากเรียนรู้ตัวเลขสุ่มอื่นๆ
นำตัวเลขทั้งหมดมารวมกันแล้วคำนวณ R ทั่วไป
เข้าสู่ระบบ;
ปัญหาที่สองคือการโจมตีคีย์ที่เป็นอันตราย มีคำอธิบายไว้อย่างดีทั้งในเอกสารและบทความนี้ ดังนั้นฉันจึงไม่ขอลงรายละเอียด แนวคิดคือหากอุปกรณ์เครื่องใดเครื่องหนึ่งของคุณถูกแฮ็ก (เช่น กระเป๋าเงินออนไลน์ของคุณ) และแสร้งทำเป็นว่ารหัสสาธารณะเป็น (p1-p2) ก็จะสามารถควบคุมเงินที่ใช้ร่วมกันได้ด้วยรหัสส่วนตัว pk1 วิธีแก้ไขง่ายๆ คือเมื่อตั้งค่าอุปกรณ์ คีย์สาธารณะจะต้องลงนามด้วยคีย์ส่วนตัวที่เกี่ยวข้อง
มีคำถามสำคัญข้อที่สาม ไม่สามารถลงชื่อด้วย deterministic k มีวิธีโจมตีง่ายๆ ถ้าคุณใช้ deterministic K จะทำให้แฮ็กเกอร์สามารถรับรหัสส่วนตัวของเราได้ การโจมตีจะมีลักษณะดังนี้: มีคนแฮ็กเข้าไปในแล็ปท็อปของเราและเข้าควบคุมคีย์ส่วนตัวหนึ่งในสองคีย์ทั้งหมด (เช่น pk1) เราอาจรู้สึกปลอดภัยเพราะ bitcoin ของเราต้องการลายเซ็นรวมจาก pk1 และ pk2 ดังนั้นเราจึงพยายามทำธุรกรรมตามปกติ เตรียมธุรกรรมที่ไม่ได้ลงนามและค่า R1 โอนไปยังกระเป๋าเงินฮาร์ดแวร์ของเราและลงนามที่นั่น จากนั้นส่งคืน (r2, s2) และ ... มีบางอย่างเกิดขึ้นกับกระเป๋าเงินออนไลน์ของเรา ไม่สามารถลงชื่อและออกอากาศได้ เราลองอีกครั้ง แต่คอมพิวเตอร์ที่ถูกแฮ็กของเราใช้ค่า R1' แบบสุ่มอีกครั้ง เราลงนามธุรกรรมเดียวกันด้วยกระเป๋าเงินฮาร์ดแวร์ของเราอีกครั้ง และนำค่า (r2, s2) กลับไปที่คอมพิวเตอร์ที่ถูกแฮ็ก จากนั้น สิ่งเลวร้ายก็เกิดขึ้น และ bitcoins ของเราก็หายไป
ในการโจมตีนี้ แฮ็กเกอร์ได้รับลายเซ็นที่ถูกต้องสำหรับธุรกรรมเดียวกัน: (R1, s1, R2, s2) และ (R1', s1', R2, s2') โดยที่ R2 เหมือนกัน แต่ R = R1 +R2 และ R'=R1'+R2 นั้นแตกต่างกัน ซึ่งหมายความว่าแฮ็กเกอร์สามารถคำนวณคีย์ส่วนตัวที่สองของเราได้: s2-s2'=(hash(P,R1+R2,m)-hash(P,R1 '+R2, ม.))⋅pk2 และ pk2=(s2-s2')/(แฮช(P,R1+R2,m)-แฮช(P,R1'+R2,m)). ฉันพบว่าคุณลักษณะนี้ไม่สะดวกที่สุดของการรวมคีย์: เราต้องการตัวสร้างตัวเลขสุ่มที่ดีทุกที่เพื่อใช้การรวมคีย์
