कोई सर्वर हमारे रहस्यों को पढ़ने के लिए कुंजियाँ पकड़े बिना कैसे संग्रहीत और सिंक्रनाइज़ कर सकता है? हम अनुसरण करेंगे कि कैसे Confidex अपनी चाबियाँ बनाता है, उन्हें लॉक में सुरक्षित रखता है और डेटा को एन्क्रिप्ट करने और परिवर्तनों को सत्यापित करने के लिए उनका उपयोग करता है।

लॉक

केवल चुना हुआ व्यक्ति ही दरवाज़ा खोल सकता है

मैट्रिक्स पुनः लोड किया गया

कल्पना करें कि हम गुप्त डेटा संग्रहीत करने के लिए एक वर्चुअल vault का निर्माण कर रहे हैं। एप्लिकेशन बंद होने के बाद उसे उस डेटा को लैपटॉप पर रखना होगा और हमें उसे किसी अन्य डिवाइस पर खोलने देना होगा। तिजोरी को अपनी चाबियों की आवश्यकता होगी। हमें उन्हें संग्रहित करना चाहिए ताकि फ़ाइलों की प्रतिलिपि बनाने से किसी बाहरी व्यक्ति को उनकी सामग्री को पढ़ने या बदलने का कोई मौका न मिले।

एक lock कुंजियों की सुरक्षा करता है: एक छोटी एन्क्रिप्टेड फ़ाइल। इसे खोलने पर एक मास्टर पासवर्ड और एक गुप्त कोड, secret_key लगता है; न तो फ़ाइल में ही है. हम सुबह के अखबार में पूरा ताला छाप सकते थे. पाठकों को एक प्रति मिलेगी, लेकिन इसे प्रकाशित करने से निजी कुंजियाँ प्रकट नहीं होंगी।

मान लीजिए कि किसी बाहरी व्यक्ति को यह फ़ाइल मिलती है और वह मास्टर पासवर्ड भी सीख लेता है। वे अब प्रत्येक गणना को दोहरा सकते हैं जिसके लिए केवल पासवर्ड की आवश्यकता होती है, लेकिन उन गणनाओं से वह कुंजी उत्पन्न नहीं होगी जो ताला खोलती है: secret_key भी एक इनपुट है। फ़ाइल में अकेले पासवर्ड की कोई अलग जांच नहीं है। इसे खोलने के लिए अभी भी अज्ञात गुप्त कोड की आवश्यकता होती है।

वह कोड क्रिप्टोग्राफ़िक रूप से यादृच्छिक डेटा से आता है; कोई व्यक्ति इसका आविष्कार नहीं करता. जब तक secret_key अज्ञात है, यहां तक ​​कि एक सही ढंग से अनुमान लगाया गया मास्टर पासवर्ड भी लॉक नहीं खोलता है: हमलावर के पास अभी भी एक यादृच्छिक रहस्य का अभाव है। इसलिए केवल एक कमजोर पासवर्ड ही सर्वर कॉपी को व्यावहारिक शब्दकोश हमले में नहीं बदल देता है।

यदि हमलावर को secret_key भी प्राप्त होता है, तो वे मास्टर-पासवर्ड अनुमानों का ऑफ़लाइन परीक्षण कर सकते हैं। यह महंगा है, लेकिन अंतिम कठिनाई पासवर्ड की मजबूती पर निर्भर करती है।

कुंजियाँ

सज्जनों, चाबियाँ क्या करती हैं? चाबियाँ... चीज़ें अनलॉक करें?

पाइरेट्स ऑफ द कैरेबियन - डेड मैन्स चेस्ट

एप्लिकेशन ऑपरेटिंग सिस्टम के क्रिप्टोग्राफ़िक जनरेटर से 32 यादृच्छिक बाइट्स प्राप्त करता है और उन्हें कुंजी के रूप में उपयोग के लिए तैयार करता है। ये तैयार बाइट्स निजी मास्टर कुंजी, master_key हैं।

एप्लिकेशन हमेशा master_key से समान कुंजी प्राप्त करता है: समान बाइट्स पर समान गणना दोहराने से समान परिणाम मिलता है। इसलिए एक लैपटॉप और एक फ़ोन समान कुंजियाँ पुनर्प्राप्त कर सकते हैं। किसी नए डिवाइस पर master_key प्राप्त करने के लिए, एप्लिकेशन को पहले मास्टर पासवर्ड और secret_key के साथ लॉक खोलना होगा।

पहली जोड़ी: एन्क्रिप्शन

मैं कीमास्टर हूं.

घोस्टबस्टर्स

एन्क्रिप्टेड डेटा को संग्रहीत करने के लिए, एप्लिकेशन master_key: secret_key से एक सार्वजनिक कुंजी की गणना करता है। यह वॉल्ट के लिए डेटा एन्क्रिप्ट कर सकता है, जबकि डिक्रिप्शन के लिए master_key की आवश्यकता होती है।

"सार्वजनिक" एल्गोरिथम में इस कुंजी की भूमिका का वर्णन करता है, न कि इसे हर किसी को देने की बाध्यता का। Confidex में यह उपयोगकर्ता के पास रहता है। यह ताला खोलने के लिए आवश्यक दूसरा रहस्य भी है, इसलिए यह स्थानीय रहता है और नेटवर्क पर नहीं भेजा जाता है। अपने आप, secret_key किसी को वॉल्ट के लिए डेटा एन्क्रिप्ट करने देता है, लेकिन उसे डिक्रिप्ट नहीं करने देता या उसकी ओर से परिवर्तनों पर हस्ताक्षर नहीं करने देता।

X25519 वह एल्गोरिथम है जो master_key से secret_key की गणना करता है. master_key को secret_key से वापस प्राप्त करना व्यावहारिक रूप से असंभव है. प्रति सेकंड 10^18 कर्व ऑपरेशन करने वाले एक काल्पनिक सुपरकंप्यूटर पर भी एक शास्त्रीय हमले में औसतन लगभग 2.3 ट्रिलियन वर्ष लगेंगे (SafeCurves का अनुमान).

दूसरी जोड़ी: हस्ताक्षर

केवल हस्ताक्षर ही मूल चीज़ है

यदि हो सके तो मुझे पकड़ लो

पहली जोड़ी सामग्री को छिपाने में मदद करती है। अब हमें यह पुष्टि करने का एक तरीका चाहिए कि तिजोरी के मालिक ने बदलाव के लिए अधिकृत किया है। सर्वर को हस्ताक्षरों की जांच करने में भी सक्षम होना चाहिए, इसलिए हमें इसे एक सार्वजनिक सत्यापन कुंजी भेजने की आवश्यकता है। पहली जोड़ी का सार्वजनिक भाग secret_key है, जिसे सर्वर को प्राप्त नहीं करना चाहिए। इसलिए हम हस्ताक्षर के लिए दूसरी, स्थायी कुंजी जोड़ी बनाते हैं।

किसी अन्य स्वतंत्र रहस्य को संग्रहीत करने के बजाय, हम master_key से एक निजी हस्ताक्षर कुंजी प्राप्त करते हैं और इसे signing_key कहते हैं। एप्लिकेशन इसका उपयोग डेटा पर हस्ताक्षर करने और लॉक करने के लिए करता है। अन्य डिवाइस और सर्वर सामग्री को पढ़े बिना हस्ताक्षर की जांच करने के लिए इसके सार्वजनिक भाग का उपयोग करते हैं।

हम इस जोड़ी को उसी master_key से पुनर्प्राप्त कर सकते हैं। एप्लिकेशन इससे एक प्रारंभिक मान प्राप्त करता है: 32 बाइट्स जो विशिष्ट रूप से हस्ताक्षर कुंजी निर्धारित करते हैं।

विभिन्न नौकरियों के लिए अलग-अलग कुंजी प्राप्त करने के लिए, हम गणना में एक निश्चित लेबल शामिल करते हैं: यहां, confidex/vault/ed25519/v1। वही master_key और वही लेबल हमेशा एक ही कुंजी उत्पन्न करता है।

मास्टर पासवर्ड ने इन गणनाओं में प्रवेश नहीं किया है। दोनों जोड़े master_key के यादृच्छिक बाइट्स पर निर्भर करते हैं, किसी व्यक्ति द्वारा आविष्कृत स्ट्रिंग पर नहीं। यह अंतर बाद में मायने रखेगा: पासवर्ड पहले से मौजूद कुंजियों तक पहुंच की रक्षा करेगा, इसलिए हम कुंजियों को बदले बिना इसे बदल सकते हैं।

व्युत्पत्ति एक हैश-आधारित कुंजी व्युत्पत्ति फ़ंक्शन का उपयोग करती है: HKDF, HMAC-based Extract-and-Expand Key Derivation Function। Confidex इसका उपयोग SHA-256 के साथ करता है, इसलिए नाम HKDF-SHA256 है। परिणामी 32 बाइट्स Ed25519 जोड़ी के लिए seed हैं। signing_key का सार्वजनिक भाग secret_key को प्रकट नहीं करता है, इसलिए हम इसे हस्ताक्षर सत्यापन के लिए सर्वर पर भेज सकते हैं।

लॉक फ़ाइल क्या है और यह क्या करती है?

पॉड बे के दरवाज़े खोलो, एचएएल.
माफ़ करना, डेव. मुझे डर है कि मैं ऐसा नहीं कर सकता.

एक अंतरिक्ष ओडिसी

लॉक एक एन्क्रिप्टेड master_key संग्रहीत करता है। इसे खोलने के लिए मास्टर पासवर्ड और secret_key की आवश्यकता होती है। सार्वजनिक हेडर में प्रारूप संस्करण, वॉल्ट पहचानकर्ता, signing_key का सार्वजनिक भाग, एक नमक और पासवर्ड-प्रसंस्करण पैरामीटर शामिल हैं। आंतरिक प्रारूप संस्करण master_key के साथ एन्क्रिप्ट किया गया है।

लॉक बनाते समय, एप्लिकेशन में पहले से ही master_key होता है, इसलिए यह एन्क्रिप्शन से पहले secret_key की गणना करता है। इसे खोलते समय, उपयोगकर्ता अलग से secret_key प्रदान करता है: यह लॉक की सार्वजनिक प्रतिलिपि से अनुपस्थित है।

डिक्रिप्शन के बाद, एप्लिकेशन X25519 का उपयोग करके master_key के सार्वजनिक भाग की गणना करता है और इसे secret_key से मेल खाने की आवश्यकता होती है। फिर यह signing_key को पुनर्प्राप्त करता है और हेडर में कुंजी के साथ इसके सार्वजनिक भाग की तुलना करता है। इस तरह लॉक अपने आप चेक हो जाता है.

मास्टर-पासवर्ड अनुमान को धीमा करने के लिए, प्रत्येक प्रयास में समय और मेमोरी खर्च होनी चाहिए। Confidex 64 MiB मेमोरी और तीन पास के साथ Argon2id का उपयोग करता है। पासवर्ड प्रोसेसिंग में यादृच्छिक नमक का भी उपयोग किया जाता है। नमक गुप्त नहीं है: यह एक ही पासवर्ड को अलग-अलग तालों में अलग-अलग परिणाम देता है।

यदि secret_key पहले से ही ज्ञात है, तो पासवर्ड की लंबाई हमले के पैमाने को नाटकीय रूप से बदल देती है। 5 यादृच्छिक लोअरकेस लैटिन अक्षरों के लगभग 12 मिलियन संयोजन हैं, 7 के लगभग 8 बिलियन और 12 के लगभग 95 क्वाड्रिलियन। 7 से 12 अक्षरों तक जाने पर खोज स्थान लगभग 12 मिलियन गुना बढ़ जाता है। यदि किसी मशीन पर 7 अक्षरों को खोजने में औसतन एक दिन लगता है, तो 5 को खोजने में लगभग दो मिनट लगेंगे, और 12 को लगभग 33,000 वर्ष लगेंगे।

Argon2id परिणाम और secret_key से एक कुंजी प्राप्त करने के लिए, हम confidex/lock/wrap/v1 लेबल के साथ पहले प्रस्तुत किए गए HKDF-SHA256 फ़ंक्शन का उपयोग करते हैं। परिणाम wrapping_key है, वह कुंजी जो ताले को एन्क्रिप्ट करती है।

हमें master_key को छिपाना चाहिए और इसे छेड़छाड़ से बचाना चाहिए। XChaCha20-Poly1305 इसे wrapping_key के साथ एन्क्रिप्ट करता है और एक प्रमाणीकरण टैग जोड़ता है। टैग सिफरटेक्स्ट को सार्वजनिक हेडर से बांधता है: एक गलत पासवर्ड या संरक्षित बाइट्स में बदलाव से ओपनिंग विफल हो जाती है। टैग और एक यादृच्छिक एकल-उपयोग मान, nonce, सिफरटेक्स्ट के साथ संग्रहीत होते हैं।

हर बार जब लॉक बनाया जाता है या दोबारा एन्क्रिप्ट किया जाता है, तो एप्लिकेशन को एक ताज़ा नमक और nonce प्राप्त होता है। एन्क्रिप्टेड सामग्री में एक संस्करण बाइट और master_key के 32 बाइट्स शामिल हैं; एक 24-बाइट nonce और एक 16-बाइट टैग उनके साथ संग्रहीत हैं। एल्गोरिदम का दस्तावेज़ीकरण निर्माण का वर्णन करता है।

पुनर्प्राप्त कुंजियों के बीच बेमेल जानबूझकर विकृत लॉक या इसे बनाने वाले प्रोग्राम में बग के कारण हो सकता है। रैंडम बाइट भ्रष्टाचार का आमतौर पर पहले ही पता चल जाता है, जब टैग की जाँच की जाती है।

सर्वर के पास इस टैग की जाँच के लिए आवश्यक रहस्य नहीं हैं। लॉक को स्थानांतरित करने के लिए, एप्लिकेशन signing_key से बना एक हस्ताक्षर जोड़ता है। यह सार्वजनिक हेडर और एन्क्रिप्टेड सामग्री सहित संपूर्ण तैयार फ़ाइल को कवर करता है। सर्वर हस्ताक्षर की जाँच करता है और, पहले अपलोड पर, signing_key के पूर्ण सार्वजनिक भाग और आंतरिक वॉल्ट पहचानकर्ता को पिन करता है। यह इस कुंजी के विरुद्ध बाद के परिवर्तनों की जाँच करता है। लॉक और एन्क्रिप्टेड डेटा को उसी signing_key से हस्ताक्षरित किया गया है, जिसे master_key से पुनर्प्राप्त किया गया है।

तिजोरी

अब हम लॉक प्रकाशित कर सकते हैं. केवल वही व्यक्ति जो secret_key और master password को जानता है, वह master_key पढ़ सकता है, जबकि कोई भी लॉक फ़ाइल से सार्वजनिक हस्ताक्षर कुंजी ले सकता है और लॉक या डेटा की सामग्री को देखे बिना हस्ताक्षरित डेटा की जांच कर सकता है।

एक पासवर्ड पर विचार करें, SuperPa55worD. अभी के लिए, हम केवल इसे सहेजना चाहते हैं: एप्लिकेशन को बंद करने के बाद, हमें लॉक फ़ाइल और एन्क्रिप्टेड पासवर्ड को बिना किसी को देखे कहीं भी भेजने में सक्षम होना चाहिए SuperPa55worD, जबकि अभी भी उन्हें हमारे लेखकत्व को सत्यापित करने की अनुमति है। जब हमारे पास secret_key और master password हो तो एन्क्रिप्शन प्रतिवर्ती होना चाहिए। एक सममित सिफर एक ही कुंजी से एन्क्रिप्ट और डिक्रिप्ट कर सकता है। चूँकि हम उस चाबी को संग्रहीत नहीं करते हैं, इसलिए हमें लॉक का उपयोग करके उसे पुनर्प्राप्त करने में सक्षम होना चाहिए। हम इसे message_key कहेंगे.

हम प्रत्येक नए एन्क्रिप्शन के लिए एक अलग message_key प्राप्त करेंगे। हमें अभी भी इसकी पुनर्प्राप्ति की व्यवस्था करने की आवश्यकता है: सिफरटेक्स्ट के बगल में कुंजी को खुले में छोड़ने से कॉपी वाला कोई भी व्यक्ति सब कुछ पढ़ सकेगा।

ताजा यादृच्छिक बाइट्स से, एप्लिकेशन केवल इस एन्क्रिप्शन के लिए एक अस्थायी X25519 जोड़ी बनाता है: record_key। इसके बाद यह record_key का निजी भाग और वॉल्ट की स्थायी सार्वजनिक कुंजी, secret_key लेता है, और एक साझा रहस्य की गणना करता है। उस रहस्य से एक अलग फ़ंक्शन message_key प्राप्त होता है; यह कुंजी हमारे पासवर्ड को एन्क्रिप्ट करती है।

पढ़ते समय, एप्लिकेशन दूसरा मार्ग अपनाता है। यह master_key और record_key के सार्वजनिक भाग का उपयोग करता है। ये दो कुंजियाँ समान साझा रहस्य उत्पन्न करती हैं। गणितीय रूप से, दोनों मार्ग वक्र पर एक ही प्रारंभिक बिंदु को एक अलग क्रम में दो निजी संख्याओं से गुणा करते हैं। आदेश परिणाम नहीं बदलता. इसलिए हम record_key के निजी भाग को रखे बिना डिक्रिप्शन कुंजी पुनर्प्राप्त कर सकते हैं।

दो सार्वजनिक कुंजियों से इस रहस्य को प्राप्त करना व्यावहारिक रूप से असंभव है: किसी भी मार्ग को संबंधित निजी कुंजी की आवश्यकता होती है। सार्वजनिक बिंदु हमें उन निजी नंबरों को कुशलतापूर्वक पुनर्प्राप्त करने की अनुमति नहीं देते हैं जिन्होंने उन्हें उत्पन्न किया है। यह गणितीय युक्ति तिजोरी की सुरक्षा को रेखांकित करती है। लेकिन यह किसी को हमारे ताले से जुड़ी एक अलग तिजोरी देने से नहीं रोकता है।

अब हम सिफरटेक्स्ट को record_key के सार्वजनिक भाग के साथ संग्रहीत कर सकते हैं। भविष्य में पढ़ने के लिए record_key के निजी भाग और प्रयुक्त message_key की अब आवश्यकता नहीं है। बाद में, एप्लिकेशन master_key से डिक्रिप्शन कुंजी और record_key के संग्रहीत सार्वजनिक भाग को पुनर्प्राप्त करता है। इस प्रकार एक स्थायी वॉल्ट रहस्य कई अलग-अलग एन्क्रिप्टेड मानों को डिक्रिप्ट कर सकता है, जिनमें से प्रत्येक का अपना message_key जरूरत पड़ने पर पुनर्प्राप्त किया जा सकता है।

पाठ को छिपाना ही पर्याप्त नहीं है: हमें इसे पढ़ते समय छेड़छाड़ का भी पता लगाना चाहिए। इसलिए एन्क्रिप्शन एक प्रमाणीकरण टैग जोड़ता है, एन्क्रिप्टेड डेटा के साथ एक संक्षिप्त मूल्य की जाँच की जाती है। यदि जाँच विफल हो जाती है, तो आवेदन परिणाम को अस्वीकार कर देता है। इसे सफलतापूर्वक डिक्रिप्ट किए गए पासवर्ड के रूप में यादृच्छिक या परिवर्तित पाठ प्रदर्शित नहीं करना चाहिए।

हमने एक निर्माण का वर्णन किया है जिसमें एक असममित जोड़ी एक साझा रहस्य स्थापित करने में मदद करती है, जबकि message_key सामग्री को एन्क्रिप्ट करती है। इसे Hybrid Public Key Encryption, या HPKE कहा जाता है, और इसे RFC 9180 में निर्दिष्ट किया गया है। Confidex रहस्य पर सहमत होने के लिए X25519, कुंजी प्राप्त करने के लिए HKDF-SHA256 और अखंडता जांच के साथ एन्क्रिप्शन के लिए ChaCha20-Poly1305 का उपयोग करता है। यहां, HKDF record_key और master_key जोड़ी का उपयोग करके सहमत साझा रहस्य लेता है; यह Ed25519 seed प्राप्त करने से अलग कार्य है। RFC 5869 वर्णन करता है HKDF।

अगले एन्क्रिप्शन के लिए, एप्लिकेशन एक नया record_key और एक नया HPKE संदर्भ बनाता है। message_key और nonce के संयोजन का पुन: उपयोग करने से सिफर की सुरक्षा टूट जाती है। Confidex में, कुंजी और nonce को HPKE के अंदर प्राप्त किया जाता है, एक संदेश के लिए उपयोग किया जाता है, और फिर संदर्भ को छोड़ दिया जाता है।

चाचा20 स्वयं 256-बिट message_key का उपयोग करता है। प्रत्यक्ष हमले की भावना प्राप्त करने के लिए, प्रति सेकंड एक अरब अरब उम्मीदवारों का परीक्षण करने वाले एक काल्पनिक सुपर कंप्यूटर की कल्पना करें। 2²⁵⁶ संभावित कुंजियाँ खोजने में लगभग 1.8 × 10⁵¹ वर्ष लगेंगे। RFC 8439 एल्गोरिथम और उसके विश्लेषण का वर्णन करता है।

एक रिकार्ड

हम खुश हैं?

पल्प फिक्शन

हमने पासवर्ड सहेज लिया है, लेकिन किसी वेबसाइट में लॉग इन करने के लिए आमतौर पर उपयोगकर्ता नाम और पते की भी आवश्यकता होती है। कभी-कभी हमें उनके पास एक नोट की आवश्यकता होती है। यदि हम इन मानों को अलग-अलग संग्रहीत करते हैं, तो एप्लिकेशन को किसी तरह याद रखना चाहिए कि वे एक साथ हैं। आइए इन "कागजातों" को एक लिफाफे में रखें। हम फ़ील्ड्स को एक संग्रह में जोड़ते हैं और इसे record कहते हैं।

एक रिकॉर्ड में फ़ील्ड का कोई भी संयोजन हो सकता है। एप्लिकेशन उन्हें एक पैकेट में इकट्ठा करता है, उसे संपीड़ित करता है और हमारे द्वारा अभी वर्णित निर्माण का उपयोग करके पूरे को एन्क्रिप्ट करता है। फ़ील्ड मान, नाम, प्रकार और टैग सभी सुरक्षित हैं। वेबसाइट का पता बदलने से, एक ही पासवर्ड रखते हुए भी, पूरे रिकॉर्ड का एक नया संस्करण बन जाता है, जो एक नए record_key के साथ एन्क्रिप्ट किया जाता है।

हैश-चेन

क्या आपके प्रोजेक्ट में ब्लॉकचेन का उपयोग होना चाहिए? → नहीं

एक्सकेसीडी 2267

कोई व्यक्ति जो secret_key जानता है वह हमारी तिजोरी के लिए एक एन्क्रिप्टेड रिकॉर्ड तैयार कर सकता है। इसे हमारा मानने से बचने के लिए, एप्लिकेशन प्रत्येक रिकॉर्ड संस्करण पर signing_key से हस्ताक्षर करता है। इस कुंजी के बिना, कोई बाहरी व्यक्ति हस्ताक्षर वाला संस्करण नहीं बना सकता जिसे सर्वर और अन्य डिवाइस स्वीकार करेंगे।

एन्क्रिप्टेड संस्करण को कुछ संबंधित जानकारी की आवश्यकता होती है: यह किस वॉल्ट और रिकॉर्ड का है, यह कब बदला, और इसके पहले कौन से संस्करण थे। यह सार्वजनिक हेडर बनाता है. इसमें पासवर्ड नहीं है, लेकिन फिर भी इसे सुरक्षा की आवश्यकता है: अन्यथा कोई सिफरटेक्स्ट को छुए बिना ऑब्जेक्ट के स्वामित्व और संबंधों को बदल सकता है। एप्लिकेशन सिफरटेक्स्ट के साथ सटीक हेडर बाइट्स पर हस्ताक्षर करता है। हस्ताक्षरित डेटा को बदलने से हस्ताक्षर अमान्य हो जाता है।

सर्वर सीलबंद पार्सल के गोदाम जैसा दिखता है। यह हेडर, एन्क्रिप्टेड सामग्री और हस्ताक्षर देखता है, लेकिन अंदर पासवर्ड नहीं देखता है, और यह जानता है कि प्राप्तकर्ता शहर में मौजूद है। यह signing_key के पिन किए गए सार्वजनिक भाग के विरुद्ध हस्ताक्षर की जांच करता है और निर्णय लेता है कि नए संस्करण को स्वीकार करना है या नहीं। इसके लिए न तो मास्टर पासवर्ड, न ही secret_key और न ही किसी निजी कुंजी की आवश्यकता है। पढ़ते समय, क्लाइंट उसी हस्ताक्षर की जाँच करता है, फिर डिक्रिप्शन के दौरान HPKE प्रमाणीकरण टैग का उपयोग करके सामग्री और हेडर के बीच बाइंडिंग की जाँच करता है।

हस्ताक्षर संस्करणों के बीच लिंक की भी सुरक्षा करता है। सटीक हेडर और सिफरटेक्स्ट बाइट्स का SHA-256 हैश संस्करण का पहचानकर्ता बन जाता है। अगले संस्करण के शीर्षलेख में पिछले संस्करण का पहचानकर्ता शामिल है। जब हम किसी वेबसाइट का पासवर्ड बदलते हैं, तो एप्लिकेशन इस लिंक के साथ एक नया ऑब्जेक्ट बनाता है और उस पर हस्ताक्षर करता है। पुरानी वस्तु और उसके हस्ताक्षर अपरिवर्तित रहते हैं। इसलिए नए संस्करण के हस्ताक्षर को संरक्षित करते हुए पूर्ववर्ती को प्रतिस्थापित करना विफल हो जाएगा। यदि दो उपकरण स्वतंत्र परिवर्तन करते हैं, तो दोनों शाखाएँ जीवित रहती हैं; एक मर्ज किया गया संस्करण दोनों को संदर्भित कर सकता है।

ब्लॉकचेन याद है? वहाँ है :-)।

सार्वजनिक हेडर हमें डिक्रिप्ट किए बिना लिंक की जांच करने देता है, लेकिन कुछ जानकारी दृश्यमान रहती है। सर्वर पहचानकर्ताओं, संस्करण लिंक, क्लाइंट द्वारा प्रदत्त परिवर्तन समय, फ़ील्ड की संख्या और प्रत्येक फ़ील्ड मान के एन्कोडेड आकार को जानता है। एन्क्रिप्शन रिकॉर्ड की सामग्री को छुपाता है, इस संरचनात्मक जानकारी को नहीं।

सिंक

“डेटा लीक नहीं, मुफ़्त वितरित बैकअप।”

इंटरनेट मेम.

कई उपकरणों पर काम करने के लिए, हमें उनके बीच लॉक और रिकॉर्ड इतिहास को स्थानांतरित करने की आवश्यकता है। ऑब्जेक्ट प्रारूप नहीं बदलता है: हम उन्हीं एन्क्रिप्टेड बाइट्स और हस्ताक्षरों को स्थानांतरित करते हैं जो स्थानीय रूप से संग्रहीत होते हैं।

मैन्युअल स्थानांतरण के लिए, एप्लिकेशन एक ZIP संग्रह बनाता है जिसमें लॉक, सभी स्थानीय रूप से संग्रहीत एन्क्रिप्टेड रिकॉर्ड संस्करण और एक हस्ताक्षरित फ़ाइल सूची होती है। न तो पासवर्ड और न ही secret_key शामिल है। किसी अन्य डिवाइस पर, एप्लिकेशन पहले लॉक खोलता है, फिर हस्ताक्षरों की जांच करता है, रिकॉर्ड्स को डिक्रिप्ट करता है और एक स्थानीय वॉल्ट कॉपी को पुनर्स्थापित करता है। आयात ऐसे उपकरण के लिए है जहां यह वॉल्ट अभी तक मौजूद नहीं है; यह इतिहास को किसी मौजूदा प्रति के साथ विलय नहीं करता है।

एक सिंक सर्वर कार्यशील प्रतियों के बीच परिवर्तनों का आदान-प्रदान करता है। पहले अपलोड पर, यह हस्ताक्षरित लॉक प्राप्त करता है, हस्ताक्षर की जांच करता है और signing_key के सार्वजनिक भाग से सार्वजनिक वॉल्ट पते की गणना करता है। इसके बाद यह इस कुंजी और हेडर से वॉल्ट पहचानकर्ता को याद रखता है: यह सर्वर पर वॉल्ट को पंजीकृत करता है। बाद के परिवर्तनों को इस पहचानकर्ता से मेल खाना चाहिए और उसी कुंजी से हस्ताक्षर होना चाहिए।

एक नए डिवाइस को वॉल्ट एड्रेस और secret_key की आवश्यकता होती है, इसलिए एप्लिकेशन उन्हें चेकसम के साथ ट्रांसफर कोड में जोड़ता है। उपयोगकर्ता इस कोड को डिवाइस में स्थानांतरित करता है और अलग से मास्टर पासवर्ड दर्ज करता है; केवल सार्वजनिक पता ही सर्वर पर भेजा जाता है।

डाउनलोड किए गए लॉक को खोलने के बाद, एप्लिकेशन पुनर्प्राप्त कुंजियों के सार्वजनिक भागों की तुलना secret_key और हेडर से करता है, और ट्रांसफर कोड के विरुद्ध गणना किए गए पते की जांच करता है। इसके बाद यह रिकॉर्ड की जांच करने के लिए signing_key के सत्यापित सार्वजनिक भाग को सहेजता है।

सिंक्रोनाइज़ेशन के दौरान, एप्लिकेशन लापता संस्करण प्राप्त करता है और उसके परिवर्तन अपलोड करता है। सर्वर पिछले संस्करणों के हस्ताक्षरों और लिंक की जाँच करता है, स्वीकृत वस्तुओं को संग्रहीत करता है और उन्हें अन्य उपकरणों तक भेजता है। प्राप्त डेटा की जाँच करना, उसे डिक्रिप्ट करना और विवादों का समाधान करना सभी उपयोगकर्ता के उपकरणों पर होता है।

पंजीकरण के लिए किसी नाम, ईमेल पते या अलग पासवर्ड की आवश्यकता नहीं होती है। सर्वर सार्वजनिक पता, हस्ताक्षर सत्यापन कुंजी, सार्वजनिक हेडर, ऑब्जेक्ट आकार और संस्करण लिंक देखता है। यह आईपी पते और अनुरोध समय भी देखता है। मास्टर पासवर्ड, secret_key, निजी कुंजी और प्लेनटेक्स्ट रिकॉर्ड सामग्री उपयोगकर्ता के डिवाइस पर रहती है। जो कोई भी सार्वजनिक पता जानता है वह एन्क्रिप्टेड ऑब्जेक्ट डाउनलोड कर सकता है, लेकिन उन्हें पढ़ने के लिए उपयोगकर्ता के रहस्यों की आवश्यकता होती है।

ये जाँचें जाली वस्तुओं का पता लगाती हैं, लेकिन यह साबित नहीं करतीं कि सर्वर ने पूरा इतिहास और उसकी नवीनतम स्थिति दिखाई है. वह ऐसी शाखा छिपा सकता है जिसे क्लाइंट ने कभी नहीं देखा, या पुराना लेकिन संगत डेटा लौटा सकता है. हस्ताक्षर किसी एक वस्तु की प्रामाणिकता की पुष्टि करता है, सर्वर के उत्तर की पूर्णता की नहीं. उपयोगकर्ता को दूसरे डिवाइस पर बदलाव गायब दिख सकते हैं, लेकिन एक संगत पुराना इतिहास hash-chain की जाँच में सफल रहेगा.

मास्टर पासवर्ड बदलना

तो क्या परमपावन अपना पासवर्ड बदलना चाहेंगे?

हैकर्स (1995)

मास्टर पासवर्ड बदलने से केवल लॉक पुनः एन्क्रिप्ट होता है; master_key अंदर वैसा ही रहता है। इसलिए रिकॉर्ड, उनके हस्ताक्षर, secret_key और तिजोरी का पता अपरिवर्तित रहता है। नए लॉक पर उसी signing_key से हस्ताक्षर किए गए हैं।

एक पुरानी लॉक कॉपी अभी भी पुराने पासवर्ड और उसी secret_key से खुलती है; पासवर्ड बदलने से वे कुंजियाँ रद्द नहीं होतीं जो पहले ही उजागर हो चुकी हैं।

पूरी तस्वीर

लॉक master_key की सुरक्षा करता है, message_key रिकॉर्ड्स को एन्क्रिप्ट करता है, और signing_key हस्ताक्षर बनाता है। ZIP अभिलेखागार और सर्वर को हस्ताक्षर के साथ एन्क्रिप्टेड ऑब्जेक्ट प्राप्त होते हैं।