परिभाषित कार्य की लागत और परिभाषित खतरे के लिए साक्ष्य की तुलना करें—सिर्फ पेड़ के चित्र और प्रेषक-कुंजी के चित्र की नहीं।
Messaging Layer Security (MLS) और Livara का LGS1 समूह चैट की सुरक्षा के दो परस्पर बदलने योग्य प्रमाणपत्र नहीं हैं। MLS, IETF का प्रोटोकॉल मानक है; LGS1, Livara का दस्तावेज़ित उत्पाद-विशिष्ट डिज़ाइन है। निष्पक्ष तुलना का अर्थ है आर्किटेक्चर, कार्यान्वयन के साक्ष्य और उपयोगकर्ताओं को वास्तव में दिखने वाले व्यवहार को अलग रखना।
मुख्य अंतर है पेड़-आधारित साझा समूह स्थिति बनाम जोड़ीदार सत्रों से वितरित प्रेषक कुंजियाँ। कोई भी नाम अकेले नहीं बताता कि कोई विशेष ऐप हटाए गए सदस्य, पुरानी स्थिति वाले डिवाइस या समझौता-ग्रस्त कुंजी को सही ढंग से संभालता है या नहीं।
आर्किटेक्चर का अंतर
RFC 9420 एसिंक्रोनस समूह कुंजी स्थापना के लिए MLS निर्दिष्ट करता है। यह रैचेट ट्री और समूह एपॉक इस्तेमाल करता है, जिनमें बताई गई शर्तों के तहत फ़ॉरवर्ड सीक्रेसी और समझौते के बाद सुरक्षा मिलती है। समूह बढ़ने पर इसकी पेड़ संरचना कुछ कुंजी-अपडेट लागतें घटाती है।
Livara के सुरक्षा दस्तावेज़ LGS1 को हर सदस्य की हस्ताक्षरित प्रेषक श्रृंखला के रूप में बताते हैं, जो LVR1 जोड़ीदार सत्रों से वितरित होती है और सदस्यता बदलाव पर बदली जाती है। यह उत्पाद का दावा है, इस बात का साक्ष्य नहीं कि LGS1, MLS के अनुरूप है या उसका वही विश्लेषण हुआ है।
| सवाल | MLS | Livara LGS1 के दस्तावेज़ |
|---|---|---|
| साझा संरचना | रैचेट ट्री और एपॉक | हर प्रेषक की अलग श्रृंखला |
| कुंजी अपडेट | समूह स्थिति के बदलाव नए एपॉक में कमिट किए जाते हैं | नई प्रेषक कुंजियाँ सदस्यों को वितरित होती हैं |
| विनिर्देश की स्थिति | IETF मानक, RFC9420 | प्रकाशित उत्पाद-विशिष्ट विवरण |
| किसका मूल्यांकन अभी बाकी है | ऐप में एकीकरण और कार्यान्वयन | पूरा विनिर्देश, कार्यान्वयन और स्वतंत्र साक्ष्य |
यह तालिका डिज़ाइन की श्रेणियाँ बताती है। यह बेंचमार्क या सुरक्षा रैंकिंग नहीं है।
“लघुगणकीय” का क्या अर्थ है—और क्या नहीं
क्रिप्टोग्राफ़िक अपडेट पेड़ के पथ के एन्क्रिप्टेड घटकों की लघुगणकीय संख्या इस्तेमाल कर सकता है, लेकिन इससे प्रणाली का सारा काम लघुगणकीय नहीं हो जाता। संदेश अब भी वितरित करने होते हैं, क्लाइंट स्थिति रखते हैं और व्यवहार समूह की संरचना तथा कार्यों पर निर्भर करता है। पुरानी तुलना “MLS को O(log N) संदेश चाहिए जबकि LGS1 में सब कुछ तेज़ है” ने अलग-अलग लागतें मिलाईं और कोई माप नहीं दिया।
MLS आर्किटेक्चर, RFC 9750, डिलीवरी सेवा को क्रिप्टोग्राफ़िक कुंजी स्थापना से अलग मानता है। यह संदेश वितरण और समूह बदलावों के क्रम पर चर्चा करता है। यह अंतर महत्वपूर्ण है: क्लाइंट की गणना, किसी कमिट के बाइट, कुल सर्वर वितरण और दोबारा जुड़ने का ट्रैफ़िक अलग मेट्रिक हैं।
सार्थक प्रदर्शन रिपोर्ट में ये बातें होनी चाहिए:
- समूह का आकार और प्रति व्यक्ति डिवाइस की संख्या;
- कार्य सामान्य संदेश, सदस्य हटाना, कुंजी अपडेट या दोबारा जुड़ना है या नहीं;
- पहल करने वाले क्लाइंट द्वारा भेजे गए बाइट बनाम कुल डिलीवरी ट्रैफ़िक;
- लगा हुआ समय, डिवाइस मॉडल, कार्यान्वयन संस्करण और नेटवर्क परिस्थितियाँ;
- छूटे अपडेट और बार-बार सदस्यता बदलाव की लागत।
इन विवरणों के बिना “मिलीसेकंड”, “स्थिति रखने का कम ओवरहेड” या किसी विशेष समूह आकार पर श्रेष्ठता के दावे स्थापित नहीं होते।
सदस्य हटाना जीवनचक्र की जाँच है
प्रशासक द्वारा खाता हटाना सुरक्षा कहानी का केवल एक हिस्सा है। क्लाइंट को नई सदस्यता स्थिति पर सहमत होना चाहिए, उपयुक्त नई कुंजियाँ इस्तेमाल करनी चाहिए और बाहर किए गए डिवाइस को वे कुंजियाँ देने से बचना चाहिए। जिस व्यक्ति के पास पहले से पुराना सादा पाठ या पुरानी कुंजियाँ हैं, उसके पास पुरानी सामग्री की पहुँच रह सकती है; हटाने से उसकी प्रतियाँ गायब नहीं हो सकतीं।
दोनों प्रणालियों के लिए उपयोगी परीक्षण पूछता है: हटाना पूरा होने के बाद क्या हटाया गया डिवाइस नया गैर-संवेदनशील परीक्षण संदेश डिक्रिप्ट कर सकता है? क्या ऑफ़लाइन रहा सदस्य सुरक्षित ढंग से बदलावों तक पहुँच सकता है? क्या खाते के सभी डिवाइस संभाले जाते हैं? क्या इंटरफ़ेस विफलताओं या सदस्यता बदलावों को दिखाता है?
ये मूल्यांकन के लिए प्रस्तावित सवाल हैं, यहाँ किए गए परीक्षणों के परिणाम नहीं। उत्पाद तुलना को देखे गए परिणाम और परीक्षण संस्करण प्रकाशित करने चाहिए, न कि प्रशासक के सफल क्लिक को क्रिप्टोग्राफ़िक बहिष्करण के बराबर मानना चाहिए।
फ़ॉरवर्ड सीक्रेसी और बहाली सशर्त हैं
बाद में समझौता होने पर पुराने संदेश सुरक्षित रहना पुरानी गुप्त सामग्री को उपयोग से हटाने पर निर्भर करता है। भविष्य के संदेशों की सुरक्षा बहाल करना, हमलावर की संबंधित पहुँच खत्म होने के बाद नए सीक्रेट जोड़ने पर निर्भर करता है। MLS में समूह अपडेट प्रोसेस करना उस बहाली का हिस्सा है; केवल अपडेट भेजना यह नहीं कि हर सदस्य ने उसे लागू कर लिया। RFC 9420 के सुरक्षा संबंधी विचार देखें।
प्रेषक-कुंजी डिज़ाइन में पूछें कि हर प्रेषक की समझौता-ग्रस्त स्थिति कैसे बदली और फिर वितरित की जाती है। अकेली एकतरफ़ा श्रृंखला को ऐसे हमलावर से स्वतः उबरने वाला नहीं बताना चाहिए जिसे उसकी वर्तमान स्थिति पता हो। पुनर्वितरण में इस्तेमाल जोड़ीदार सुरक्षा प्रासंगिक है, लेकिन पूरे समूह-स्तरीय विश्लेषण का विकल्प नहीं।
पोस्ट-क्वांटम दावों के लिए विशिष्ट सिफर सूट और दायरा चाहिए
मूल RFC9420 में परिभाषित सिफर सूट क्लासिकल सार्वजनिक-कुंजी तंत्र इस्तेमाल करते हैं। MLS में विस्तार किया जा सकता है, इसलिए किसी विशेष कार्यान्वयन का दावा उसके वास्तविक सूट और विस्तारों को बताए, न कि सभी MLS परिनियोजनों को हमेशा के लिए क्लासिकल घोषित करे।
LGS1 द्वारा दस्तावेज़ित हाइब्रिड LVR1 वितरण का इस्तेमाल, हर समूह कार्य के लिए स्वतंत्र रूप से विश्लेषित पोस्ट-क्वांटम गारंटी से अलग दावा है। FIPS 203, ML-KEM को मानकीकृत करता है; यह उसे शामिल करने वाले पूरे समूह प्रोटोकॉल को प्रमाणित नहीं करता। केवल KEM का नाम नहीं, प्रमाणीकरण, सदस्यता बदलाव, कुंजी समझौता और कार्यान्वयन का एक साथ मूल्यांकन करें।
उत्पाद का फैसला करने से पहले क्या माँगें
वर्तमान प्रोटोकॉल विनिर्देश, परीक्षण वेक्टर और रिलीज़-विशिष्ट स्वतंत्र समीक्षा माँगें, जिसमें अनसुलझे निष्कर्ष भी हों। फिर उत्पाद की सामान्य आवश्यकताओं की तुलना करें: समर्थित डिवाइस, अपडेट का व्यवहार, पुनर्प्राप्ति, मॉडरेशन भूमिकाएँ और सर्वर द्वारा रखा गया डेटा।
MLS आर्किटेक्चर ऐप सेवाओं और उनकी भरोसे संबंधी मान्यताओं को स्पष्ट रूप से देखता है। इसी तरह Livara के खतरा मॉडल को उसके उत्पाद दावों के साथ पढ़ना चाहिए। एन्क्रिप्शन अधिकृत प्रतिभागियों को भरोसेमंद नहीं बनाता, स्क्रीनशॉट नहीं रोकता और मेटाडेटा के हर रूप को नहीं हटाता।
साक्ष्य न हों तो किसी डिज़ाइन को स्वतः असुरक्षित या श्रेष्ठ कहने के बजाय “स्थापित नहीं” दर्ज करें। फैसले में आपके समूह के जोखिम और उपलब्ध साक्ष्य की गुणवत्ता झलकनी चाहिए।
अक्सर पूछे जाने वाले सवाल
क्या LGS1, MLS का कार्यान्वयन है?
प्रकाशित विवरण अलग आर्किटेक्चर दिखाते हैं। यह लेख LGS1 को MLS कार्यान्वयन नहीं बताता और न ही परस्पर संचालन की क्षमता का दावा करता है।
क्या MLS में हर सदस्य का एक साथ ऑनलाइन होना ज़रूरी है?
नहीं। एसिंक्रोनस उपयोग उसके डिज़ाइन का हिस्सा है। ऐप को फिर भी विलंबित अपडेट, पुरानी स्थिति और लंबे समय से ऑफ़लाइन सदस्यों के लिए नीतियाँ चाहिए।
क्या पोस्ट-क्वांटम कुंजी वितरण से समूह सुरक्षा का सवाल हल हो जाता है?
नहीं। यह कुंजी स्थापना के एक हिस्से को संबोधित करता है। पहचान, सदस्यता, कुंजी जीवनचक्र, एंडपॉइंट सुरक्षा और कार्यान्वयन के लिए साक्ष्य अभी भी चाहिए।
कौन-सा डिज़ाइन तेज़ है?
इस लेख में विजेता स्थापित करने वाला कोई बेंचमार्क नहीं है। अपने समूह के लिए महत्वपूर्ण कार्यों और परिनियोजन को मापें।
