हर संदेश पर चेन को आगे बढ़ाना और पोस्ट-क्वांटम एपॉक को रीफ़्रेश करना रैचेट की समस्या के अलग-अलग हिस्से हल करते हैं।
हाइब्रिड पोस्ट-क्वांटम रैचेट क्लासिकल और पोस्ट-क्वांटम, दोनों तरह की सामग्री से मैसेजिंग कुंजियाँ अपडेट करता है। इसका उद्देश्य सावधानी से निर्धारित मान्यताओं के तहत किसी एक घटक के असुरक्षित हो जाने पर भी सुरक्षा बनाए रखना और समय के साथ खास तरह के कुंजी-समझौतों से होने वाली क्षति सीमित करना है।
Livara, P-256 और ML-KEM-768 का उपयोग करते हुए LVR1 के लिए इस तरीके का दस्तावेज़ीकरण करता है। डिज़ाइन समझने के लिए शुरुआती कुंजी स्थापना, सामान्य मैसेज-चेन अपडेट और समय-समय पर होने वाले पोस्ट-क्वांटम रीफ़्रेश को अलग-अलग समझना ज़रूरी है। ये हर संदेश पर की जाने वाली एक ही क्रिया नहीं हैं।
साझा रहस्य से बदलती संदेश कुंजियों तक
कुंजी-स्थापना तंत्र प्रतिभागियों को गुप्त सामग्री देता है, जिसका वे कुंजी व्युत्पत्ति की योजना में उपयोग कर सकते हैं। इसके बाद रैचेट प्रोटोकॉल पूरी बातचीत के लिए एक अपरिवर्तित कंटेंट कुंजी रखने के बजाय स्थिति को विकसित करता है और संदेश कुंजियाँ व्युत्पन्न करता है।
NIST FIPS 203, ML-KEM को निर्दिष्ट करता है, जिसमें ML-KEM-768 पैरामीटर सेट भी शामिल है। यह एक साझा रहस्य स्थापित करता है; AES-GCM जैसा प्रमाणीकृत साइफ़र संदेश के पेलोड को एन्क्रिप्ट करता है। प्रमाणीकरण और घटकों को जोड़ने का तरीका व्यापक प्रोटोकॉल का हिस्सा हैं।
Livara का सुरक्षा अवलोकन हाइब्रिड स्थापना, स्वतंत्र क्लासिकल और पोस्ट-क्वांटम रूट, संदेशों के साथ आगे बढ़ने वाली एकतरफ़ा भेजने/प्राप्त करने की चेन तथा समय-समय पर ML-KEM एपॉक अपडेट का वर्णन करता है। उसके अनुसार कंटेंट और हेडर की सुरक्षा से पहले संदेश कुंजी को वर्तमान पोस्ट-क्वांटम रूट के साथ जोड़ा जाता है।
इस विवरण को बदलकर यह नहीं कहना चाहिए कि “हर संदेश पर नया P-256 आदान-प्रदान और नया ML-KEM एनकैप्सुलेशन होता है।” चेन को आगे बढ़ाना अपेक्षाकृत कम लागत वाला कुंजी-व्युत्पत्ति चरण हो सकता है।
एक एपॉक क्या बदलता है
एपॉक किसी खास रीफ़्रेश से जुड़ी प्रोटोकॉल स्थिति की अवधि है। बड़े कुंजी-स्थापना संदेशों को अलग-अलग एपॉक में नियोजित करने से बार-बार होने वाला संचार ओवरहेड घट सकता है, लेकिन इससे रीफ़्रेश के नियम सुरक्षा की दृष्टि से महत्वपूर्ण भी बनते हैं।
समीक्षक को ये सवाल पूछने चाहिए:
- नया एपॉक किससे शुरू होता है: काउंटर, समय, दूसरे पक्ष की कार्रवाई या कोई अन्य शर्त?
- एपॉक पहचानकर्ताओं और कुंजी सामग्री का प्रमाणीकरण कैसे होता है?
- देर से आने वाले, दोहराए गए या क्रम से बाहर आए संदेशों का क्या होता है?
- क्लाइंट किसी छूटे अपडेट या पुराने असंगत दूसरे पक्ष को कैसे संभालता है?
- विलंबित डिलीवरी के लिए कौन-से पुराने रहस्य रखे जाते हैं और उन्हें कब हटाया जाता है?
इम्प्लीमेंटेशन को सटीक उत्तर चाहिए। केवल “समय-समय पर” शब्द रिकवरी या इंटरऑपरेबिलिटी का पूरा विनिर्देश नहीं है।
बेंचमार्क गढ़े बिना प्रिमिटिव के आकार मापना
FIPS 203 के अनुसार ML-KEM-768 की एनकैप्सुलेशन कुंजी का आकार 1,184 बाइट और साइफ़रटेक्स्ट का आकार 1,088 बाइट है। ये प्रिमिटिव की एन्कोडिंग हैं, किसी Livara संदेश या हैंडशेक का कुल आकार नहीं। प्रोटोकॉल हेडर, हस्ताक्षर, फ़्रेमिंग और हर मान कितनी बार भेजा जाता है, वास्तविक ट्रैफ़िक तय करते हैं।
P-256 कुंजियों का आकार भी निरूपण पर निर्भर करता है। उदाहरण के लिए, संपीड़ित कर्व पॉइंट और असंपीड़ित पॉइंट की एन्कोडेड लंबाइयाँ अलग होती हैं। बिना स्पष्ट निरूपण बताए “P-256 कुंजी के आकार” की तुलना ML-KEM साइफ़रटेक्स्ट से करना पूर्ण बैंडविड्थ विश्लेषण नहीं है।
रैचेट की लागत का मूल्यांकन करने के लिए प्रतिनिधि उपकरणों पर हर बातचीत और एपॉक के बाइट, CPU समय, मेमोरी, रेडियो के जागने की घटनाएँ और एंड-टू-एंड विलंब मापें। बिल्ड और नेटवर्क की परिस्थितियाँ बताएं। इन मापों के बिना न “बैटरी पर नगण्य प्रभाव” उचित है, न सभी परिस्थितियों में एक मिलीसेकंड से कम निष्पादन समय का दावा।
फ़ॉरवर्ड सीक्रेसी और समझौते के बाद रिकवरी
फ़ॉरवर्ड सीक्रेसी का लक्ष्य कुछ निर्धारित बाद के रहस्यों के उजागर होने पर पुराने संदेशों को सुरक्षित रखना है, बशर्ते आवश्यक पुराने रहस्य मिटा दिए गए हों। पोस्ट-कॉम्प्रोमाइज़ सुरक्षा का संबंध तब सुरक्षा वापस पाने से है जब हमलावर एंडपॉइंट को नियंत्रित करना बंद कर चुका हो और प्रोटोकॉल में ऐसी नई गुप्त सामग्री आए जो उसे ज्ञात न हो।
Double Ratchet विनिर्देश इन अंतरों और सेंध के बाद रिकवरी की सीमाओं को समझाता है। मैलवेयर की लगातार पहुँच, यादृच्छिकता में हेरफेर या संबंधित आदान-प्रदान को नियंत्रित करने वाला सक्रिय हमलावर अपेक्षित रिकवरी को विफल कर सकता है। एक और संदेश भेजना यह साबित नहीं करता कि चोरी हुआ सत्र निरस्त हो गया है या समझौता किया गया फ़ोन साफ़ हो गया है।
हाइब्रिड संरचना को सही प्रमाणीकरण और संयोजन की भी ज़रूरत होती है। “हमलावर को दोनों एल्गोरिदम तोड़ने होंगे” संरचना की मान्यताओं के तहत वांछित गुण है, न कि इम्प्लीमेंटेशन की त्रुटियों या दुर्भावनापूर्ण एंडपॉइंट को समेटने वाला बिना शर्त कथन।
सुविधाओं की सीमाएँ स्पष्ट रखें
Livara के दस्तावेज़ों में LGS1 समूह प्रेषक कुंजियाँ जोड़ीवार LVR1 सत्रों के ज़रिए वितरित की जाती हैं। इसका अर्थ यह नहीं कि समूह प्रेषक चेन की संरचना सीधे चैट वाले डबल रैचेट जैसी ही है। वर्तमान सुरक्षा पृष्ठ पुराने असंगत समूहों को E2EE से बाहर भी रखता है और नया एन्क्रिप्टेड समूह बनाने से पहले सदस्यों का तैयार होना आवश्यक बताता है।
अटैचमेंट की अपनी कंटेंट कुंजियाँ होती हैं, जिन्हें सुरक्षित बातचीत के भीतर पहुँचाया जाता है। कॉल और वैकल्पिक सर्वर रिकॉर्डिंग की अलग समीक्षा ज़रूरी है; केवल इसलिए मीडिया को पोस्ट-क्वांटम सुरक्षा प्राप्त न मानें कि सिग्नलिंग पथ हाइब्रिड सत्र का उपयोग करता है। सार्वजनिक चैनल और परिचालन मेटाडेटा निजी कंटेंट की गोपनीयता के दायरे से बाहर हैं।
भरोसा किससे मज़बूत होगा?
संस्करणबद्ध विनिर्देश, इंटरऑपरेबिलिटी और विफलता-स्थितियों के परीक्षण, स्वतंत्र समीक्षा तथा समीक्षा किए गए सोर्स और वितरित क्लाइंट के बीच स्पष्ट संबंध खोजें। मानक एल्गोरिदम घटकों के बारे में उपयोगी प्रमाण हैं, उनके संयोजन का प्रमाणन नहीं।
Livara का Proof Lab चुनिंदा क्लासिकल प्रिमिटिव प्रदर्शित करता है और उस स्थानीय बेंच से पूर्ण LVR1/LGS1 संयोजन को स्पष्ट रूप से बाहर रखता है। उसका थ्रेट मॉडल अब भी आवश्यक संदर्भ है। साथ मिलकर ये सामग्री सवालों को आकार देने में मदद करती है; इन्हें प्रोटोकॉल और इम्प्लीमेंटेशन के पूर्ण मूल्यांकन का विकल्प नहीं बताना चाहिए।
