FROST

मान लीजिए अन्ना, यान और एवा किसी संस्था की बचत संभालते हैं। वे 2-of-3 नियम चुनते हैं, यानी तीन में से दो लोगों की मंज़ूरी: अन्ना और यान, अन्ना और एवा, या यान और एवा भुगतान मंज़ूर कर सकते हैं। हर व्यक्ति एक अलग गुप्त हिस्सा रखता है, यानी साझा कुंजी-सामग्री का क्रिप्टोग्राफ़ी से बनाया गया अंश। एक हिस्सा पर्याप्त नहीं है, लेकिन ये एक ही पासवर्ड की तीन प्रतियाँ भी नहीं हैं। एवा उपलब्ध न हो तो बाकी दोनों मिलकर काम कर सकते हैं। यही सीमा हमलावर पर भी लागू होती है: पर्याप्त हिस्से मिल जाएँ तो वह भी हस्ताक्षर कर सकता है। इसलिए बाँटकर रखना तभी उपयोगी है जब एक उपकरण या खाते में सेंध लगने से बाकी सब तक पहुँच न खुल जाए। [1] [2]

अन्ना को केवल इसलिए कार्रवाई मंज़ूर नहीं करनी चाहिए कि ऐप हस्ताक्षर का अनुरोध दिखा रहा है। उसे प्राप्तकर्ता, रकम और शुल्क जानना चाहिए तथा यह देखना चाहिए कि बची हुई रकम संस्था को लौट रही है या नहीं। हर हस्ताक्षरकर्ता को असली लेनदेन जाँचने का भरोसेमंद तरीका चाहिए। Hash डेटा की छोटी क्रिप्टोग्राफ़िक पहचान है, लेकिन अपने आप किसी इंसान को उसका अर्थ नहीं समझाता। FROST एक ही संदेश पर सहयोग संभव करता है; वह यह नहीं परखता कि बिल असली है या व्यक्ति ने समझा है कि वह किस बात की मंज़ूरी दे रहा है। तैयार हस्ताक्षर भी ब्लॉक में भुगतान की पुष्टि नहीं है। ब्लॉक, Bitcoin नेटवर्क के साझा इतिहास में दर्ज लेनदेन का एक समूह है। RFC 9591 प्रोटोकॉल का सूचनात्मक विनिर्देश है, पूरे ऐप की सुरक्षा का प्रमाणपत्र नहीं। [1] [2]

Taproot, Bitcoin का एक सुधार है जिसमें संबंधित कुंजी के हस्ताक्षर से या पहले से तय शर्तें पूरी करके धन खर्च किया जा सकता है। ठीक तरह से बनाया गया थ्रेशोल्ड हस्ताक्षर, Taproot के कुंजी वाले मार्ग से धन खर्च करते समय, एक कुंजी से बने सामान्य हस्ताक्षर जैसा दिख सकता है। केवल हस्ताक्षर देखकर अंदरूनी हिस्सों की संख्या या आवश्यक सीमा पता नहीं चलती। इससे गोपनीयता और हस्ताक्षर डेटा के आकार में मदद मिलती है, लेकिन पूरा लेनदेन या भागीदारों की बातचीत गुमनाम नहीं हो जाती। Bitcoin को BIP 340 के सटीक नियम चाहिए; कुंजियों की गणना के गणितीय आधार secp256k1 वक्र पर सामान्य FROST का उपयोग करना ही पर्याप्त नहीं है। इसलिए Zcash Foundation (ZF) खास तौर पर Taproot के लिए frost-secp256k1-tr उपलब्ध कराती है। Taproot में होने वाले कुंजी-समायोजन भी सही तरीके से लागू करने होते हैं। वक्र का नाम समान होना अनुकूलता का प्रमाण नहीं, और लाइब्रेरी उपलब्ध होने का मतलब हर वॉलेट में समर्थन होना नहीं है। [3] [4]

किसी भी चीज़ पर हस्ताक्षर करने से पहले संस्था को हिस्से सुरक्षित तरीके से बनाने होंगे। एक भरोसेमंद वितरक पूरी कुंजी बनाकर उसे बाँट सकता है। लेकिन यह संवेदनशील क्षण है: वितरक पूरी कुंजी जानता है और बचाकर रखी गई प्रति नियोजित साझा मंज़ूरी को दरकिनार कर सकती है। दूसरा रास्ता DKG, यानी वितरित कुंजी निर्माण है, जिसमें पूरी गुप्त कुंजी किसी एक भागीदार के पास प्रकट होना ज़रूरी नहीं है। इसमें पहचान-सत्यापित, सुरक्षित संचार और प्रोटोकॉल का सही निष्पादन चाहिए। केवल कुछ फ़ाइलें ईमेल से भेजना पर्याप्त नहीं है। RFC 9591 मुख्यतः हस्ताक्षर पर केंद्रित है; वह हर उत्पाद में अपने आप DKG होने का वादा नहीं करता। लंबे समय के लिए रखा गया कुंजी का हिस्सा भी किसी खास भुगतान के हस्ताक्षर-अंश से अलग है। [1] [2]

हस्ताक्षर की प्रक्रिया दो दौर में होती है; इससे पहले का कुंजी निर्माण इसमें नहीं गिना जाता। पहले हर चुना गया भागीदार nonce नाम के दो गुप्त, एक बार इस्तेमाल होने वाले मान बनाता है और उनके सार्वजनिक कमिटमेंट भेजता है। ये मान उसे उन nonce से क्रिप्टोग्राफ़िक रूप से बाँधते हैं। फिर उसे साझा संदेश और कमिटमेंट की सूची मिलती है; वह सामग्री जाँचकर अपना हस्ताक्षर-अंश निकालता है। समन्वयक इन अंशों को जोड़ता है। बाइंडिंग फ़ैक्टर गणनाओं को खास संदेश, समूह की सार्वजनिक कुंजी और कमिटमेंट से जोड़ते हैं। 2-of-3 नियम में दो लोगों से सत्र शुरू हो सकता है। लेकिन उस सत्र में तीनों चुने गए हों तो सभी को योगदान देना होगा; जवाब देना बंद करने वाले को बस छोड़ नहीं सकते। [1] [3]

यहाँ nonce एक हस्ताक्षर-प्रयास के लिए गुप्त मान है, बार-बार इस्तेमाल होने वाला पासवर्ड नहीं। दोबारा इस्तेमाल से गुप्त कुंजी-सामग्री खुल सकती है। यान का कंप्यूटर हस्ताक्षर-अंश भेजने के बाद बंद हो जाए तो पुरानी स्थिति बहाल करते समय इस्तेमाल किए गए nonce को नया नहीं माना जा सकता। भुगतान अधूरा रह जाना भी उन्हें दोबारा इस्तेमाल करने की अनुमति नहीं देता। सुरक्षित कार्यान्वयन को अच्छी यादृच्छिकता, साथ चल रहे प्रयासों का अलगाव और इस्तेमाल हो चुके मानों को भरोसेमंद ढंग से हटाना चाहिए। इसीलिए मनमानी स्क्रिप्ट जोड़कर खुद FROST बनाना उचित नहीं है। सही गणित अकेले गुप्त डेटा के गलत प्रबंधन से सुरक्षा नहीं देता। [1]

समन्वयक संदेशों की व्यवस्था करता है, लेकिन केवल इस भूमिका से वह संस्था की ओर से हस्ताक्षर नहीं कर सकता। उसे चुने गए हिस्सा-धारकों के योगदान चाहिए। फिर भी वह संदेश रोक सकता है या सत्र बाधित कर सकता है, जैसे किसी भागीदार का अमान्य योगदान उसे विफल कर सकता है। जाँच अमान्य हस्ताक्षर-अंश पहचान सकती है; किसी खास व्यक्ति को जिम्मेदार ठहराने के लिए संदेश का स्रोत भरोसेमंद ढंग से जानना ज़रूरी है। समस्या पकड़ लेना काम पूरा होने की गारंटी नहीं है। नए प्रयास को उपलब्ध, अधिकृत समूह और नए nonce चाहिए। इसलिए संस्था को बाधाओं और मतभेदों के लिए योजना चाहिए, केवल शुरुआती स्क्रीन पर सीमा की संख्या नहीं। [1] [2]

एवा का उपकरण खो जाए तो FROST नाम अपने आप धन वापस नहीं लाएगा। बैकअप में उसका हिस्सा, पहचान-संकेत, समूह की आवश्यक जानकारी और उन्हें अनुकूल सॉफ़्टवेयर में खोलने का तरीका बचा रहना चाहिए। यह अपने आप साधारण Seed Phrase नहीं है, यानी शब्दों में लिखा वॉलेट बैकअप। दूसरों की मदद से हिस्सा बहाल करना और हिस्सों का नवीनीकरण अतिरिक्त प्रक्रियाएँ हैं, जिन्हें उस प्रणाली को समर्थन देना होगा। एवा के हिस्से की प्रति वही हिस्सा रहती है; वह स्वतंत्र वोट नहीं जोड़ती। समूह की कुंजी समान रखते हुए नवीनीकरण भी पहले चुराए गए पर्याप्त हिस्सों को निष्प्रभावी नहीं करता। इसलिए असली बचत लगाने से पहले परीक्षण में बहाली, बाधाएँ और सॉफ़्टवेयर का सटीक संस्करण शामिल होना चाहिए, केवल एक सफल हस्ताक्षर नहीं। [2] [3]