क्रिप्टोग्राफ़िक पहचान की पुनर्प्राप्ति, खाते में दोबारा लॉगिन और चैट इतिहास की पुनर्प्राप्ति तीन अलग काम हैं। Livara के सुरक्षा दस्तावेज़ों के अनुसार, v7 फ़ॉर्मैट क्रिप्टोग्राफ़िक पहचान की पुनर्प्राप्ति के लिए है; यह फ़ॉर्मैट अपने-आप चैट इतिहास वापस नहीं लाता।
इस आर्किटेक्चर को “किसी भी क्लाउड बैकअप के बिना” भी नहीं कहना चाहिए। मौजूदा दस्तावेज़ कहता है कि पहचान संबंधी सामग्री डिवाइस पर एन्क्रिप्ट होती है और फिर एन्क्रिप्ट किए गए बैकअप के रूप में अपलोड होती है। महत्वपूर्ण अंतर सर्वर पर पढ़ने योग्य कुंजी रखने और ऐसी एन्क्रिप्ट की हुई प्रति रखने में है जिसे खोलने के लिए रिकवरी कुंजी चाहिए।
तीन दरवाज़े, जिनकी चाबी एक नहीं है
| प्रक्रिया | उद्देश्य | यह पर्याप्त क्यों नहीं है? |
|---|---|---|
| खाते में लॉगिन | सेवा खाते तक पहुँच के अधिकार को साबित करना | पुराने संदेशों को डिक्रिप्ट करने की कुंजी आवश्यक रूप से नहीं देता |
| पहचान पुनर्प्राप्ति | क्रिप्टोग्राफ़िक पहचान की सामग्री तक दोबारा पहुँच | अकेले सभी संदेशों के मौजूद होने या वापस मिलने का प्रमाण नहीं |
| इतिहास पुनर्प्राप्ति | आवश्यक संदेश और अटैचमेंट वापस लाना | कुंजी के अलावा मूल डेटा और समर्थित पुनर्प्राप्ति विधि भी चाहिए |
यह अंतर एक महँगी गलती से बचाता है: यह मानकर पुराना फ़ोन मिटा देना कि लॉगिन पासवर्ड जानना सभी बातचीत वापस लाने के लिए पर्याप्त है।
v7 के दस्तावेज़ वास्तव में क्या कहते हैं?
Livara का सुरक्षा पृष्ठ बताता है कि P-256 की कुंजी-सहमति और हस्ताक्षर कुंजियाँ तथा ML-KEM सीड डिवाइस पर एक यादृच्छिक 256-बिट रिकवरी कुंजी के अंतर्गत एन्क्रिप्ट होते हैं। v7 फ़ॉर्मैट के विवरण में एल्गोरिदम सूट, पहचान युग और पीढ़ी की प्रामाणिकता भी सत्यापित की जाती है। यह निर्माता का दस्तावेज़ है और अपने-आप कार्यान्वयन का स्वतंत्र ऑडिट नहीं बन जाता।
Livara का थ्रेट मॉडल कुंजी बैकअप खोलने के लिए रिकवरी वाक्यांश को आवश्यक बताता है। इस विवरण से वाक्यांश को कुंजी में बदलने के सटीक एल्गोरिदम या सभी कुंजियों को सीधे पुनर्निर्मित करने का अनुमान नहीं लगाना चाहिए। व्यावहारिक विवरण ऐप के संस्करण और उसी संस्करण की मार्गदर्शिका से मिलाने चाहिए।
व्युत्पत्ति फ़ंक्शन कमज़ोर वाक्यांश को मज़बूत क्यों नहीं बनाता?
फ़ंक्शन के आउटपुट की लंबाई और इनपुट का अनुमान लगाना कितना कठिन है, ये एक ही बात नहीं हैं। RFC 5869 स्पष्ट करता है कि HKDF मौजूदा एंट्रॉपी को केंद्रित करता है, बढ़ाता नहीं। इसलिए यह दावा नहीं किया जा सकता कि कोई भी मनचाहा वाक्यांश HKDF से गुज़रते ही अपने-आप पूरी 256-बिट सुरक्षा पा लेता है।
ऐप की आधिकारिक प्रक्रिया में बने वाक्यांश को अपनी मर्ज़ी से छोटा न करें, दोबारा न लिखें और आसानी से अनुमान लगाए जा सकने वाले वाक्य से न बदलें। उसे किसी व्यक्ति, सहायता बॉट या अनजान फ़ॉर्म को न भेजें।
फ़ोन बदलने या मिटाने से पहले
- ऐप में पुष्टि करें कि किसका बैकअप है: पहचान, इतिहास या दोनों का अलग-अलग तरीकों से।
- रिकवरी वाक्यांश उसी फ़ोन से स्वतंत्र, सुरक्षित स्थान पर रखें; दूसरों की उस तक पहुँच को गंभीर जोखिम मानें।
- मौजूदा संस्करण की पुनर्प्राप्ति मार्गदर्शिका पढ़ें। केवल “लॉगिन सफल” संदेश को पूरी पुनर्प्राप्ति का परिणाम न मानें।
- यदि पुनर्प्राप्ति परीक्षण का तरीका समर्थित है, तो पहले गैर-संवेदनशील डेटा से और एकमात्र मौजूदा प्रति मिटाए बिना परीक्षण करें।
- स्थानांतरण के बाद आवश्यक बातचीत और फ़ाइलें जाँचें; उसके बाद पुराने डिवाइस को छोड़ने का निर्णय लें।
यदि मेरे पास रिकवरी वाक्यांश नहीं है तो?
यदि आपके पास अभी भी अधिकृत डिवाइस है, तो केवल उसी ऐप के अंदर उपलब्ध आधिकारिक रास्ते देखें; संस्करण देखे बिना नया बैकअप बनाने की सुविधा मानकर न चलें। यदि डिवाइस और वाक्यांश दोनों खो गए हैं, तो Livara का दस्तावेज़ कुंजी वापस दिलाने का वादा नहीं करता। किसी “गारंटीशुदा डिक्रिप्शन” सेवा को इस सीमा का विकल्प न मानें।
खाता स्थानांतरण की योजना “कौन-सा डेटा, किस कुंजी से, किस बैकअप से वापस आएगा?” पूछकर शुरू करें, न कि यह मानकर कि दोबारा लॉगिन का अर्थ सारी चैट वापस मिलना है।
