संदेश की अखंडता: क्या सर्वर एन्क्रिप्टेड चैट बदल सकता है?

किसी मैसेंजर में संपादन या हटाने की सुविधा हो सकती है; लेकिन प्रमाणित एन्क्रिप्शन वाले तंत्र में सर्वर को एन्क्रिप्टेड पाठ चुपचाप बदलकर फिर भी वैध संदेश पहुँचाने में सक्षम नहीं होना चाहिए। मैसेंजर में संदेश की अखंडता का अर्थ है कि प्राप्तकर्ता एन्क्रिप्शन के बाद डेटा में हुआ बदलाव पहचान सके; यह पूरा इतिहास सुरक्षित रखने या बातचीत को कानूनी रूप से साबित करने के समान नहीं है।

मुख्य बातें

• प्रमाणित एन्क्रिप्शन सिफरटेक्स्ट में छेड़छाड़ दिखाता है, लेकिन संपादन और हटाने का इतिहास आवश्यक रूप से नहीं रखता।
• Livara के तकनीकी दस्तावेज़ों के अनुसार, AES-256-GCM निजी संदेशों को प्रामाणिकता टैग के साथ सुरक्षित करता है; छेड़छाड़ वाला पैकेट वैध रूप से डिक्रिप्ट नहीं होना चाहिए।
• अधिकृत संपादन एक नई, एंड-टू-एंड एन्क्रिप्टेड घटना होना चाहिए, न कि सर्वर द्वारा पिछले पैकेट को चुपके से फिर लिखना।
• सुरक्षा नंबर दूसरे व्यक्ति की कुंजी जाँचने में मदद करते हैं, उसकी ईमानदारी या स्क्रीनशॉट की कानूनी वैधता मापने में नहीं।
• संवेदनशील विवादों के लिए मूल फ़ाइल, समय, संपादन स्थिति और स्वतंत्र सबूत बातचीत की थ्रेड के बाहर भी रखें।

मैसेंजर में संदेश की अखंडता वास्तव में क्या है?

संदेश की अखंडता का अर्थ है कि प्राप्तकर्ता एन्क्रिप्टेड डेटा में अनधिकृत बदलाव पहचान सके। गोपनीयता पूछती है, «पाठ कौन पढ़ सकता है?»; अखंडता पूछती है, «क्या वही डेटा पहुँचा जिसे भेजने वाले ने एन्क्रिप्ट किया था?» एंड-टू-एंड एन्क्रिप्शन और उसकी सीमाओं का विवरण इस अंतर को और समझाता है।

यह उदाहरण के लेबल वाला वैचारिक चित्र है; यह Livara का वास्तविक इंटरफ़ेस या छेड़छाड़ वाले संदेश को अस्वीकार करने के परीक्षण का परिणाम नहीं है।

Livara के तकनीकी दस्तावेज़ों के अनुसार, सीधे संदेश LVR1 से और संगत निजी समूह LGS1 से एंड-टू-एंड एन्क्रिप्ट होते हैं। Livara के सुरक्षा पृष्ठ के अनुसार, असंगत पुराना समूह स्पष्ट रूप से E2EE से बाहर रहता है और नया समूह तब तक एन्क्रिप्टेड लेबल के साथ नहीं बनाया जाता जब तक सभी सदस्य तैयार न हों। उसी बातचीत की स्थिति जाँचें। दस्तावेज़ बताते हैं कि LVR1 संदेश कुंजी निकालने के लिए ECDH P-256 और ML-KEM-768 का उपयोग करता है। किसी एक घटक का मानक होना पूरे संयोजन या उत्पाद का स्वतंत्र अनुमोदन नहीं है। इसके बाद Livara सामग्री की रक्षा के लिए AES-256-GCM इस्तेमाल करता है।

उत्पाद के दस्तावेज़ों के अनुसार, यह सुरक्षा निजी बातचीत के पाठ, संपादन और संलग्नकों को शामिल करती है। लेकिन Livara चैनल एंड-टू-एंड एन्क्रिप्टेड नहीं हैं: सर्वर जानबूझकर उनकी सामग्री पढ़ सकता है ताकि, अन्य कामों के साथ, दुरुपयोग वाली सामग्री हटा सके। समूह सदस्यता भी सर्वर के नियंत्रण में है। कॉल की सुरक्षा और रिकॉर्डिंग मोड को भी पाठ संदेश से अलग जाँचना चाहिए।

एन्क्रिप्टेड संदेश में छेड़छाड़ की पहचान और मैसेंजर का AES-256-GCM

AES-GCM सामग्री एन्क्रिप्ट करने के साथ प्रामाणिकता टैग बनाता है। सिफरटेक्स्ट या प्रमाणित डेटा बदले तो टैग की जाँच विफल होनी चाहिए। NIST SP 800-38D GCM मोड परिभाषित करता है और चेताता है कि एक ही कुंजी के साथ nonce दोहराने से सुरक्षा गंभीर रूप से कमजोर हो सकती है।

Livara की तकनीकी विशिष्टताओं के अनुसार, निजी संदेश AES-256-GCM इस्तेमाल करते हैं। सर्वर सुरक्षित पैकेट का कोई हिस्सा बदले तो संदेश कुंजी के बिना नया प्रामाणिकता टैग नहीं बना सकता; इसलिए प्राप्तकर्ता को पैकेट सही मानकर स्वीकार नहीं करना चाहिए। «क्या सर्वर संदेश बदल सकता है?» का छोटा उत्तर है: सर्वर डेटा हटा सकता है, रोककर रख सकता है, ब्लॉक कर सकता है या देर से पहुँचा सकता है, लेकिन छेड़छाड़ वाली सामग्री को वैध नहीं दिखा सकना चाहिए।

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

क्या सर्वर संदेश बदल सकता है, या संपादन अलग चीज़ है?

सर्वर को पिछले एन्क्रिप्टेड पैकेट को छिपकर फिर नहीं लिख सकना चाहिए, लेकिन वह भेजने वाले की बनाई संपादन घटना पहुँचा सकता है। संदेश संपादन की सुरक्षा इस बात पर निर्भर है कि संपादन भी मूल संदेश की तरह प्रमाणित और एंड-टू-एंड एन्क्रिप्टेड हो, न कि सर्वर संग्रहीत पाठ को सीधे बदल दे।

Livara के दस्तावेज़ों के अनुसार, सीधी चैट में संपादन LVR1 के अंतर्गत और संगत निजी समूह में LGS1 के अंतर्गत सुरक्षित है। इंटरफ़ेस का मूल्यांकन करते समय जाँचें कि ऐप «संपादित» स्थिति दिखाता है या नहीं; फिर भी केवल एन्क्रिप्शन पिछले संस्करण को सभी उपकरणों पर हमेशा के लिए नहीं रखता।

«सभी के लिए हटाएँ» भी सामग्री त्यागने का अनुरोध है, सभी प्रतियों के नष्ट होने का प्रमाण नहीं। प्राप्तकर्ता संदेश देख चुका हो सकता है, सूचना पढ़ सकता है, फ़ाइल सहेज सकता है या स्क्रीनशॉट ले सकता है। गायब होने वाले संदेश प्रतियों के बने रहने को घटाते हैं, लेकिन सभी प्रतियाँ मिटाने की गारंटी नहीं देते।

चैट संदेश का प्रमाणीकरण क्या साबित करता है?

चैट संदेश का प्रमाणीकरण दिखाता है कि संदेश सत्र कुंजियों से बना और रास्ते में छेड़ा नहीं गया। यह साबित नहीं करता कि खाता मालिक ने खुद उपकरण पकड़ा था, पाठ सच है या प्राप्तकर्ता बाद में किसी तीसरे पक्ष को इसे निर्णायक रूप से साबित कर सकता है।

Livara अपने तकनीकी दस्तावेज़ों में सुरक्षा नंबरों को कुंजी का बदलाव पहचानने का तरीका बताता है। दो लोग स्वतंत्र माध्यम से कुंजियों के फ़िंगरप्रिंट मिला सकते हैं; सुरक्षा नंबरों से चैट जाँचने की मार्गदर्शिका व्यावहारिक चरण समझाती है। यह जाँच संपर्क की कुंजी को हमलावर की कुंजी से बदलने का जोखिम घटाती है, लेकिन संक्रमित उपकरण को सुरक्षित नहीं बनाती।

खाते का प्रमाणीकरण भी अलग मुद्दा है। कोई भी लॉगिन व्यवस्था, कितनी भी मजबूत हो, संदेश की अखंडता, संपर्क की कुंजी जाँच या उपकरण की सुरक्षा की जगह नहीं लेती।

सामग्री की अखंडता संदेश के क्रम और नवीनता के समान नहीं है

किसी पुराने पैकेट में वैध प्रामाणिकता टैग हो सकता है। उसे दोबारा स्वीकार करने से रोकने के लिए प्रोटोकॉल का डिज़ाइन, काउंटर, सत्र पहचानकर्ता और प्राप्तकर्ता की स्थिति बनाए रखना जरूरी है; अकेला AES-GCM पूरी बातचीत के क्रम की बही नहीं है। रीप्ले, देर से आने वाले संदेश और कई उपकरणों के समन्वयन का मूल्यांकन करते समय यह अंतर महत्वपूर्ण है।

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

यदि संदेश का पाठ या स्थिति अप्रत्याशित हो

ऐप का संस्करण, देखने का समय, संबंधित उपकरण और संपादन लेबल की मौजूदगी दर्ज करें। स्वतंत्र माध्यम से संपर्क से पूछें कि क्या उसने अधिकृत संपादन किया है। बिना सबूत समन्वयन का अंतर सर्वर की छेड़छाड़ न मानें; लेकिन प्रामाणिकता त्रुटि या कुंजी के बदलाव को भी बिना कारण अनदेखा न करें।

तकनीकी रिपोर्ट के लिए गैर-संवेदनशील परीक्षण संदेश इस्तेमाल करें और सार्वजनिक रिपोर्ट में संपर्क का निजी डेटा न डालें। बातचीत कानूनी मामले में इस्तेमाल होनी हो तो केवल एन्क्रिप्शन या स्क्रीनशॉट कानूनी वैधता तय नहीं करता; सबूत बदलने से पहले योग्य विशेषज्ञ की मदद लें।

मैसेंजर के अखंडता संबंधी दावे को कैसे परखें?

केवल «एन्क्रिप्टेड» शब्द से संतुष्ट न हों। पूछें:

• कौन-सी बातचीत और फ़ाइलें एंड-टू-एंड एन्क्रिप्ट होती हैं?
• सेवा कौन-सा AEAD एल्गोरिदम इस्तेमाल करती है?
• संपादन और हटाना कैसे दर्ज और प्रदर्शित होते हैं?
• उपयोगकर्ता संपर्क की कुंजी का बदलाव कैसे पहचानता है?
• सर्वर किस मेटाडेटा, सामग्री या सदस्यता को नियंत्रित करता है?
• क्या कॉल को संदेशों जैसी ही गारंटियाँ मिलती हैं?
• क्या प्रोटोकॉल का स्वतंत्र ऑडिट हुआ है?

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

निजी बातचीत के लिए Livara का मुख्य दावा सीमित और स्पष्ट है: AES-256-GCM को पैकेट की छेड़छाड़ उजागर करनी चाहिए और संपादन भी एन्क्रिप्ट होने चाहिए। इसका अर्थ अपरिवर्तनीय बही, सभी प्रतियों का निश्चित विलोपन या अपने आप कानूनी सबूत बन जाना नहीं है।

अक्सर पूछे जाने वाले सवाल

क्या सर्वर प्रशासक एन्क्रिप्टेड संदेश का पाठ बदल सकता है?

AES-256-GCM के सही डिज़ाइन में सर्वर प्रशासक संदेश कुंजी के बिना सिफरटेक्स्ट बदलकर वैध प्रामाणिकता टैग नहीं बना सकता। वह फिर भी पैकेट हटा सकता है, ब्लॉक कर सकता है या देर से पहुँचा सकता है। यह गारंटी संक्रमित उपकरण या भेजने वाले के अधिकृत संपादन को शामिल नहीं करती।

क्या «संपादित» लेबल साबित करता है कि पिछला संस्करण क्या था?

नहीं। जब तक ऐप संस्करणों का इतिहास भी न रखे, यह लेबल केवल बताता है कि प्रदर्शित सामग्री भेजने के बाद बदली है। एन्क्रिप्शन संपादन घटना की प्रामाणिकता जाँच सकता है, लेकिन पिछले पाठ को अपने आप नहीं बचाता।

क्या सुरक्षा नंबर सभी संदेशों की प्रामाणिकता की गारंटी देता है?

नहीं। सुरक्षा नंबर यह जाँचने में मदद करता है कि एन्क्रिप्शन कुंजी संपर्क की है और उसका बदलाव पहचानता है। यह जाँच नहीं बताती कि भेजते समय उपकरण किसके हाथ में था, संदेश सच है या उपकरण में मैलवेयर नहीं है।

क्या सभी के लिए हटाने से संदेश हर जगह से मिट जाता है?

नहीं। यह सुविधा ऐप की प्रति हटा सकती है, लेकिन सहेजी फ़ाइल, सूचना, स्क्रीनशॉट या पहले का रिकॉर्ड वापस नहीं लेती। सभी के लिए हटाना प्रतियों के बने रहने को घटाता है; प्राप्तकर्ता के उपकरण या दूसरे तंत्रों से मिटने की गारंटी नहीं देता।