एन्क्रिप्टेड स्टोरेज फ़ाइल के बाइट और उसे डिक्रिप्ट करने की क्षमता को अलग रखता है, लेकिन प्राप्तकर्ता, मेटाडेटा और स्थानीय कॉपियाँ थ्रेट मॉडल का हिस्सा बने रहते हैं।
एंड-टू-एंड एन्क्रिप्टेड अटैचमेंट सर्वर को प्लेनटेक्स्ट फ़ाइल दिए बिना वहाँ रखा जा सकता है। एक सामान्य डिज़ाइन भेजने वाले के डिवाइस पर नई कंटेंट कुंजी से फ़ाइल एन्क्रिप्ट करता है, सिफ़रटेक्स्ट अपलोड करता है और प्रमाणित एन्क्रिप्टेड संदेश के अंदर कुंजी इच्छित प्राप्तकर्ताओं को भेजता है।
यह अलगाव उपयोगी है, लेकिन “ज़ीरो-नॉलेज स्टोरेज” पूरा विनिर्देश नहीं है। आपको फिर भी पूछना होगा कि कुंजियाँ, फ़ाइल संदर्भ, फ़ाइल नाम, एक्सेस नियंत्रण और डाउनलोड की गई कॉपियाँ कैसे संभाली जाती हैं।
अटैचमेंट का जीवनचक्र
- फ़ाइल तैयार करें। भेजने वाला फ़ोटो, वीडियो या दस्तावेज़ चुनता है। मेटाडेटा हटाना या ट्रांसकोडिंग अलग चरण है; केवल एन्क्रिप्शन EXIF या दस्तावेज़ के गुण नहीं हटाता।
- एन्क्रिप्शन सामग्री बनाएँ। सुरक्षित कार्यान्वयन चुनी गई योजना के अनुसार आवश्यक कुंजी और nonce सामग्री बनाता है।
- अपलोड से पहले एन्क्रिप्ट करें। स्टोरेज सेवा को मूल सामग्री की जगह एन्क्रिप्टेड बाइट मिलते हैं।
- प्रमाणित संदर्भ पहुँचाएँ। एन्क्रिप्टेड चैट संदेश प्राप्तकर्ताओं के लिए ज़रूरी जानकारी ले जाता है, जैसे फ़ाइल का स्थान-सूचक, डिक्रिप्शन कुंजी और संबंधित अखंडता मेटाडेटा।
- प्राप्त करें और सत्यापित करें। प्राप्तकर्ता का क्लाइंट blob प्राप्त करता है और परिणाम को वैध सामग्री मानने से पहले प्रमाणीकरण जाँचता है।
- स्थानीय कॉपियाँ संभालें। दिखाने, एक्सपोर्ट करने, संपादन करने या गैलरी में सहेजने से मूल एन्क्रिप्टेड-स्टोरेज सीमा के बाहर कॉपियाँ बन सकती हैं।
कुंजी उसी प्रदाता के बुनियादी ढाँचे से एन्क्रिप्टेड आवरण में गुज़र सकती है। इसे “आउट ऑफ़ बैंड” कहना भ्रामक हो सकता है: यह blob स्टोरेज से तार्किक रूप से अलग है, ज़रूरी नहीं कि स्वतंत्र संचार चैनल से पहुँचाई गई हो।
प्रमाणित एन्क्रिप्शन क्या जोड़ता है
प्रमाणित एन्क्रिप्शन योजना गोपनीयता की रक्षा करती है और अपने प्रमाणित दायरे के भीतर अनधिकृत बदलाव पहचानती है। NIST का GCM विनिर्देश ऐसी एक संरचना और उसकी आवश्यकताएँ परिभाषित करता है। कुंजी/nonce का सही प्रबंधन और प्रमाणीकरण परिणाम की जाँच अनिवार्य हैं; मान्यता-प्राप्त एल्गोरिदम का नाम हर कार्यान्वयन को सुरक्षित नहीं बनाता।
ऐप को फ़ाइल सही संदेश और बातचीत से भी बाँधनी चाहिए। वैध एन्क्रिप्टेड blob अपने-आप प्रमाण नहीं कि वह इसी खास चैट का है। फ़ाइल पहचानकर्ता, अपेक्षित आकार, चंक का क्रम और अटैचमेंट मेटाडेटा के लिए उचित प्रमाणित डिज़ाइन चाहिए।
स्टोरेज सेवा फिर भी क्या जान सकती है
| जानकारी | क्या केवल कंटेंट एन्क्रिप्शन इसे छिपाता है? |
|---|---|
| मूल फ़ाइल बाइट | इसे कुंजी न रखने वाले पक्षों से छिपाने के लिए बनाया गया है |
| एन्क्रिप्टेड आकार का अनुमान | आम तौर पर नहीं |
| अपलोड और डाउनलोड का समय | आम तौर पर नहीं |
| कौन-सा खाता फ़ाइल माँगता है | रूटिंग और एक्सेस-कंट्रोल डिज़ाइन पर निर्भर |
| फ़ाइल नाम और कैप्शन | तभी, जब प्रोटोकॉल उनकी भी रक्षा करे |
| प्राप्तकर्ता द्वारा सहेजी गई कॉपी | नहीं; प्राप्तकर्ता को प्लेनटेक्स्ट तक पहुँच पहले से है |
blob एन्क्रिप्टेड होने पर भी एक्सेस नियंत्रण महत्त्वपूर्ण हैं। वे अनचाहे डाउनलोड, दुरुपयोग और पहचानकर्ताओं के खुलासे को सीमित कर सकते हैं। एन्क्रिप्शन प्राधिकरण, भंडारण नीतियों या उपलब्धता का विकल्प नहीं है।
बड़ी फ़ाइलों को एक नारे से अधिक चाहिए
बड़ी फ़ाइल का डिज़ाइन डेटा स्ट्रीम कर सकता है या उसे प्रमाणित चंक में बाँट सकता है। इससे मेमोरी उपयोग घट सकता है, लेकिन चंक का क्रमांक, अंतिम लंबाई, दोबारा प्रयास और अधूरा कटने का प्रबंधन परिभाषित होना चाहिए। प्रदर्शन के आँकड़े न गढ़ें और यह दावा न करें कि संदेश में फ़ाइल रखने से अनिवार्य रूप से “ratchet स्टेट का आकार बढ़ता ही जाता है”; ये परिणाम कार्यान्वयन पर निर्भर करते हैं।
उपयोगी परीक्षण में वैध फ़ाइल, बदला हुआ बाइट, अधूरा डाउनलोड, क्रम बदला हुआ चंक और अनधिकृत प्राप्ति का प्रयास शामिल हैं। ऐसे परीक्षण केवल अधिकृत परीक्षण वातावरण में गैर-संवेदनशील फ़ाइलों से करें। रिकॉर्ड करें कि क्लाइंट अमान्य डेटा खोलने से पहले अस्वीकार करता है या नहीं।
Livara क्या दस्तावेज़ित करता है
Livara का सुरक्षा पृष्ठ अपलोड से पहले एन्क्रिप्शन, संरक्षित सत्र के भीतर भेजी गई हर फ़ाइल की अलग यादृच्छिक कुंजी, और सक्रिय E2EE वाली बातचीत में फ़ाइल नामों तथा कैप्शन की सुरक्षा बताता है; इसमें संगत निजी समूह शामिल हैं। पुराने असंगत समूह स्पष्ट रूप से इस दायरे से बाहर हैं। यह संरक्षित बातचीत और सार्वजनिक प्रसारण चैनलों में अंतर करता है। ये दस्तावेज़ित उत्पाद-दावे हैं, इस लेख में किया गया नया कार्यान्वयन ऑडिट नहीं।
थ्रेट मॉडल यह भी मानता है कि प्राप्तकर्ता या सेंध लगा हुआ डिवाइस पढ़ने योग्य सामग्री उजागर कर सकता है। इसलिए एन्क्रिप्टेड स्टोरेज यह वादा नहीं कर सकता कि चैट संदेश मिटने पर तस्वीर हर डिवाइस से गायब हो जाएगी।
संवेदनशील फ़ाइलें साझा करने से पहले पूछने वाले सवाल
जाँचें कि बातचीत का प्रकार E2EE समर्थित करता है, सभी इच्छित प्राप्तकर्ता भरोसेमंद हैं और फ़ाइल में पहचान उजागर करने वाला मेटाडेटा तो नहीं। गैलरी में अपने-आप सहेजना और क्लाउड फ़ोटो बैकअप अलग से देखें। दस्तावेज़ के लिए विचार करें कि भेजने से पहले टिप्पणियाँ, संशोधन इतिहास या अंतर्निहित गुण हटाने चाहिए या नहीं।
अंत में, मिटाने और पुनर्प्राप्ति को समझें। सर्वर blob हटाने से भविष्य का डाउनलोड रुक सकता है, लेकिन प्राप्तकर्ता की मौजूदा कॉपी वापस नहीं ली जा सकती। आवश्यक कुंजी खोने से बची हुई एन्क्रिप्टेड फ़ाइल अपठनीय हो सकती है। अच्छा अटैचमेंट डिज़ाइन दोनों परिणाम स्पष्ट रूप से समझाता है।
