ब्राउज़र मजबूत क्रिप्टोग्राफी चला सकता है; ब्राउज़र को दिए गए कोड पर फिर भी भरोसा करना पड़ता है।
ब्राउज़र किसी नेटिव मैसेजिंग ऐप को इंस्टॉल किए बिना स्थानीय रूप से एंड-टू-एंड एन्क्रिप्शन कर सकता है, जिसमें पोस्ट-क्वांटम कुंजी स्थापना भी शामिल है। कठिन सवाल यह नहीं है कि गणित किसी टैब में चल सकता है या नहीं। सवाल यह है कि दिया गया एप्लिकेशन, कुंजियों का प्रबंधन और अपडेट का रास्ता उस भरोसे के योग्य हैं या नहीं जिसकी बातचीत को जरूरत है।
जब इंस्टॉल करना संभव न हो, तब वेब-आधारित पहुँच सुविधाजनक हो सकती है। इससे ऐप सेंसरशिप, समझौता हो चुके होस्टिंग सिस्टम, दुर्भावनापूर्ण एक्सटेंशन या समझौता हो चुके डिवाइस से सुरक्षित नहीं हो जाता।
ब्राउज़र के क्रिप्टोग्राफिक निर्माण खंड
WebCrypto एन्क्रिप्शन, कुंजी व्युत्पत्ति, हस्ताक्षर और कुंजी प्रबंधन के लिए निम्न-स्तरीय ऑपरेशन उपलब्ध कराता है। आम कार्यान्वयन AES-GCM और ECDH जैसे मूल क्रिप्टोग्राफिक घटक देते हैं। ये ऑपरेशन निर्माण खंड हैं, कोई पूर्ण प्रमाणीकृत मैसेजिंग प्रोटोकॉल नहीं।
जहाँ जरूरी नेटिव API उपलब्ध न हो, वहाँ वेब एप्लिकेशन JavaScript या WebAssembly का उपयोग करके ML-KEM का समीक्षा किया हुआ कार्यान्वयन जोड़ सकता है। ब्राउज़र समर्थन बदलता रहता है, इसलिए डेवलपर को यह मानने के बजाय कि हर ब्राउज़र समान एल्गोरिदम देता है, ठीक उन्हीं लक्षित संस्करणों में सुविधाओं की उपलब्धता जाँचनी चाहिए।
एक वैचारिक हाइब्रिड प्रवाह इस प्रकार है:
- क्रिप्टोग्राफिक रूप से सुरक्षित यादृच्छिकता से उपयुक्त कुंजियाँ बनाएँ।
- प्रोटोकॉल की पहचान व्यवस्था से दूसरे पक्ष की कुंजी सामग्री प्रमाणीकृत करें।
- साझा रहस्य में शास्त्रीय और पोस्ट-क्वांटम योगदान प्राप्त करें।
- निर्दिष्ट कुंजी-व्युत्पत्ति क्रम और बातचीत के संदर्भ का उपयोग करके उन्हें जोड़ें।
- nonce और स्थिति को सही ढंग से संभालते हुए व्युत्पन्न कुंजियों से प्रमाणीकृत एन्क्रिप्शन करें।
यह समझाने वाली रूपरेखा है, कार्यान्वयन की विधि नहीं। FIPS 203 ML-KEM को मानकीकृत करता है; यह किसी खास ब्राउज़र एप्लिकेशन को प्रमाणित नहीं करता और न ही चैट प्रोटोकॉल का हर चरण परिभाषित करता है।
HTTPS से कोड मिलना भरोसे के मॉडल का हिस्सा है
सर्वर आम तौर पर वह JavaScript और WebAssembly देता है जो प्लेनटेक्स्ट को संसाधित करेंगे। दुर्भावनापूर्ण ढंग से बदला गया एप्लिकेशन एन्क्रिप्शन से पहले या डिक्रिप्शन के बाद संदेश पढ़ सकता है, भले ही उसकी क्रिप्टोग्राफिक लाइब्रेरी मजबूत एल्गोरिदम इस्तेमाल करती हो।
HTTPS डिलीवरी को प्रमाणीकृत करने और नेटवर्क हस्तक्षेप से बचाने में मदद करता है। यह साबित नहीं करता कि मूल साइट का संचालक, उसकी डिप्लॉयमेंट प्रणाली या उसकी निर्भरताएँ समझौते से मुक्त हैं। सामान्य HTTPS वेब पेज अपने-आप स्वतंत्र रूप से हस्ताक्षरित एप्लिकेशन पैकेज नहीं बन जाता।
W3C के WebCrypto सुरक्षा विचार स्क्रिप्ट इंजेक्शन और एप्लिकेशन की अखंडता बचाने की जरूरत पर चर्चा करते हैं। Content Security Policy, निर्भरताओं का सावधानीपूर्वक प्रबंधन और अन्य वेब सुरक्षा नियंत्रण जोखिम घटाते हैं, लेकिन इनमें से कोई भी उसी ओरिजिन की मनमानी स्क्रिप्ट को ऐसे अविश्वसनीय पर्यवेक्षक में नहीं बदलता जो एप्लिकेशन के डेटा को छू ही न सके।
WebAssembly भी एप्लिकेशन की सुरक्षा सीमा साझा करता है। उसका सैंडबॉक्स परिभाषित इंटरफेस के जरिए होस्ट तक पहुँच सीमित करता है; वह उसे कॉल करने वाले पेज को भरोसेमंद नहीं बनाता। C को Wasm में कंपाइल करने से मूल भाषा मेमोरी-सुरक्षित नहीं हो जाती।
कुंजियाँ जरूरी नहीं कि केवल RAM में हों
ब्राउज़र मैसेंजर कुंजियाँ या एन्क्रिप्टेड स्थिति स्थायी रूप से रख सकता है ताकि उपयोगकर्ता उसी पहचान के साथ लौट सके। वह डिवाइस लिंकिंग या एन्क्रिप्टेड रिकवरी भी दे सकता है। इन व्यवहारों को अनुपस्थित मान लेने के बजाय दस्तावेजित करना चाहिए।
पूछने योग्य सवालों में शामिल हैं:
- कौन-सी कुंजियाँ स्थायी रूप से रखी जाती हैं और ब्राउज़र के किस स्टोरेज में?
- साइट डेटा साफ करने या निजी ब्राउज़िंग सत्र समाप्त होने पर क्या होता है?
- क्या एप्लिकेशन के संदर्भ में चल रहा दुर्भावनापूर्ण कोड ऐसी कुंजी का भी उपयोग कर सकता है जिसे एक्सपोर्ट नहीं किया जा सकता?
- क्या नया दिया गया अपडेट पुरानी स्थानीय स्थिति तक पहुँच सकता है?
- रिकवरी पहचान वापस लाती है, संदेशों का इतिहास या दोनों?
एक गैर-निष्कर्षणीय WebCrypto कुंजी API के जरिए एक्सपोर्ट सीमित करती है। वह अपने-आप विरोधी एप्लिकेशन कोड को अनुमत ऑपरेशन माँगने या प्लेनटेक्स्ट इकट्ठा करने से नहीं रोकती।
वेब और नेटिव क्लाइंट में अलग-अलग समझौते होते हैं
| विषय | ब्राउज़र क्लाइंट | नेटिव क्लाइंट |
|---|---|---|
| वितरण | ओरिजिन, होस्टिंग और वेब अपडेट की पाइपलाइन | ऐप स्टोर या पैकेज वितरण और हस्ताक्षर की पाइपलाइन |
| स्थानीय स्थायी संग्रह | ब्राउज़र स्टोरेज और प्रोफाइल का व्यवहार | OS में ऐप का स्टोरेज और एप्लिकेशन का जीवनचक्र |
| जोखिम का संपर्क | उसी ओरिजिन की स्क्रिप्ट, एक्सटेंशन और ब्राउज़र की कमजोरियाँ | एप्लिकेशन की निर्भरताएँ और OS/ऐप की कमजोरियाँ |
| उपलब्धता | पहुँच योग्य डोमेन और जरूरी नेटवर्क सेवाएँ | इंस्टॉल किए गए ऐप को भी अपनी जरूरी नेटवर्क सेवाएँ चाहिए |
कार्यान्वयन की जाँच किए बिना कोई भी कॉलम विजेता तय नहीं करता। ऐप स्टोर से हटाए जाने के बाद वेब ऐप उपलब्ध रह सकता है, लेकिन ब्लॉक किया गया डोमेन या अनुपलब्ध नेटवर्क मार्ग फिर भी पहुँच रोक सकता है।
प्रदर्शन के वादे करने के बजाय उसे मापें
FIPS 203 के अनुसार ML-KEM-768 में 1,184-बाइट की एनकैप्सुलेशन कुंजी और 1,088-बाइट का साइफरटेक्स्ट होता है। ये आकार समझाते हैं कि प्रोटोकॉल हर छोटे संदेश के साथ नई सामग्री जोड़ने के बजाय KEM अपडेट क्यों निर्धारित कर सकते हैं। ये पूरे एप्लिकेशन की बैंडविड्थ या गति के माप नहीं हैं।
उपयोगी बेंचमार्क में ब्राउज़र, डिवाइस, बिल्ड, वार्म-अप विधि, मापा गया ऑपरेशन और समय के मापों का वितरण बताया जाता है। पेज की शुरुआत, मॉड्यूल लोडिंग, मेमोरी उपयोग, कम क्षमता वाले डिवाइस और नेटवर्क ओवरहेड शामिल करें। “सभी आधुनिक फोन पर दो मिलीसेकंड से कम” जैसे दावों के लिए प्रकाशित माप चाहिए; यह लेख ऐसे माप नहीं देता।
इसे Livara पर लागू करना
Livara का सुरक्षा अवलोकन LVR1 और उसकी रिकवरी सीमाओं का दस्तावेजीकरण करता है। उसका Proof Lab चुने हुए स्थानीय P-256, HKDF और AES-GCM ऑपरेशन प्रदर्शित करता है; पेज स्पष्ट रूप से पूर्ण LVR1/LGS1 संयोजन को उस बेंच के दायरे से बाहर रखता है। इसलिए सफल प्रदर्शन वितरित किए गए पूरे वेब कोड की सुरक्षा साबित नहीं करता।
ब्राउज़र में संवेदनशील बातचीत से पहले प्रामाणिक और रखरखाव वाला क्लाइंट इस्तेमाल करें, वर्तमान खतरा मॉडल देखें, ब्राउज़र प्रोफाइल सुरक्षित रखें और समर्थित कुंजी-जाँच प्रक्रिया से दूसरे पक्ष का सत्यापन करें। सुविधा और उपयोगी क्रिप्टोग्राफी साथ रह सकती हैं, बशर्ते वेब से डिलीवरी की सीमा आकलन का हिस्सा बनी रहे।
