182 / 691FROST

FROST

FROST सीमा-आधारित Schnorr हस्ताक्षर

FROST कुंजी-अंश धारकों को मिलकर एक Schnorr हस्ताक्षर बनाने देता है। सुरक्षा सीमा, कुंजी निर्माण, एकबारगी nonce और हर सहभागी वास्तव में क्या मंजूर करता है, इस पर निर्भर है।

FROST का पूरा नाम Flexible Round-Optimized Schnorr Threshold है। इस सीमा-आधारित हस्ताक्षर प्रोटोकॉल में पर्याप्त सहभागी साझा सार्वजनिक कुंजी के अंतर्गत हस्ताक्षर करते हैं, बिना हस्ताक्षर के दौरान पूरी गुप्त कुंजी एक जगह जोड़कर बनाने के।

3 में से 2 वाली व्यवस्था में दो उपलब्ध अधिकृत अंश पर्याप्त हैं; एक से हस्ताक्षर नहीं बनता। दो अंश पाने वाला हमलावर भी सीमा पूरी कर सकता है। दीर्घकालीन कुंजी-अंश किसी विशेष संदेश का आंशिक हस्ताक्षर नहीं है; हस्ताक्षर के लिए नए एकबारगी मानों वाला संयुक्त प्रोटोकॉल चाहिए। [RFC 9591 — FROST]

विश्वसनीय वितरक रहस्य बनाकर अंश बाँट सकता है, इसलिए वह पूरी कुंजी जानता है और उसे सुरक्षित सँभालना चाहिए। DKG ऐसे एकल वितरक के बिना संयुक्त निर्माण देता है, लेकिन उसका अपना संचार और सत्यापन होता है। RFC 9591 मुख्यतः हस्ताक्षर बताता है; वितरक वाला परिशिष्ट यह नहीं दर्शाता कि हर तैनाती अपने आप DKG अपनाती है। [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]

पहले दौर में सहभागी दो गुप्त nonce बनाता और उनकी सार्वजनिक प्रतिबद्धताएँ साझा करता है। दूसरे में संदेश, सहभागी सूची और अपनी प्रतिबद्धताएँ जाँचकर हस्ताक्षर-अंश निकालता है। समन्वयक अंश जोड़ता है। बंधन गुणक nonce को विशेष संदेश और प्रतिबद्धता समूह से जोड़ते हैं; इन दो दौरों में पहले का कुंजी निर्माण नहीं गिना जाता। [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]

nonce का दोबारा उपयोग गुप्त कुंजी सामग्री उजागर कर सकता है। उपयोग के बाद गुप्त nonce सुरक्षित रूप से हटाना आवश्यक है, प्रयास रुक जाने पर भी; पुराने बैकअप की बहाली उसे फिर उपयोग योग्य न बनाए। यादृच्छिकता, समवर्ती सत्र और उपयोग का स्थायी लेखा सुरक्षा का हिस्सा हैं, केवल गति बढ़ाने के उपाय नहीं। [RFC 9591 — FROST]

समन्वयक प्रतिबद्धताएँ और हस्ताक्षर-अंश जुटाता है; पर्याप्त कुंजी-अंश के बिना उसे अकेले हस्ताक्षर करने की शक्ति नहीं मिलती। फिर भी वह संदेश रोक सकता या प्रयास बंद करा सकता है। दोषपूर्ण अंश की जाँच उसका निर्माता पहचान सकती है, सत्र पूरा होने की गारंटी नहीं देती। प्रमाणित संचार और पर्याप्त उपलब्ध सहभागी जरूरी रहते हैं। [RFC 9591 — FROST]

Bitcoin के लिए परिणाम को BIP 340 की सटीक एन्कोडिंग, हैशिंग और नियमों तथा जरूरी Taproot कुंजी समायोजन का पालन करना चाहिए। सामान्य FROST क्रिप्टो-सूट में secp256k1 चुनना भर पर्याप्त नहीं। ZF, Taproot के लिए अलग frost-secp256k1-tr देता है; विशिष्ट सूट और उसके परीक्षण जाँचें। चेन पर एक हस्ताक्षर अपने आप आंतरिक सीमा नहीं बताता। [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]

अंश को सही पहचानकर्ता, समूह की सार्वजनिक जानकारी और संगत सॉफ्टवेयर चाहिए। दूसरे सहभागियों की मदद से खोया अंश बहाल करना या अंश नवीकृत करना अतिरिक्त प्रोटोकॉल हैं जिन्हें तैनाती वास्तव में समर्थन दे। उसी अंश की प्रतिलिपि स्वतंत्र सहभागी नहीं बढ़ाती। बैकअप को सीमा बनाए रखते हुए खर्च हो चुके nonce की वापसी रोकनी चाहिए। [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]

हर हस्ताक्षरकर्ता को समन्वयक का हैश आँख मूँदकर हस्ताक्षर करने के बजाय प्राप्तकर्ता, राशि, शुल्क और मंजूरी नियम जाँचने चाहिए। FROST संयुक्त हस्ताक्षर हल करता है, व्यावसायिक इरादे की सही होने की पुष्टि नहीं। उपयोग से पहले कार्यान्वयन संस्करण, बहाली और विफलता व्यवहार जाँचें; सूचनात्मक RFC पूरे वॉलेट का प्रमाणन नहीं है। [RFC 9591 — FROST]

पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Schnorr signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing.

DOC · 001RFC 9591 — FROSTविनिर्देशDOC · 002ZF FROST Book — key generation and recoveryप्राथमिक स्रोतDOC · 003ZF frost-secp256k1-tr — Taproot implementationप्राथमिक स्रोतDOC · 004BIP 340 — Schnorr Signatures for secp256k1विनिर्देश
स्रोत पहले · यह निवेश सलाह नहीं है