नॉलेज बेस

सिरे-से-सिरे तक एन्क्रिप्शन

आपके browser में बनी OpenPGP कुंजियाँ। किसी दूसरे OpenEmail address को भेजी जाने वाली मेल tab छोड़ने से पहले सील की जा सकती है, और आपको भेजी गई सीलबंद मेल reading pane में खुलती है, आपकी मशीन पर डिक्रिप्ट होकर। कुंजियाँ कभी हमारी नहीं होतीं कि हम उन्हें सौंप सकें।

विवरण

दोनों आधे सिरे से सिरे तक जुड़े हैं। जिस प्राप्तकर्ता की कुंजी प्रकाशित है, उसे लिखते समय अनुरोध के निकलने से पहले ही browser में body सील हो जाता है; server को ऐसा armour मिलता है जिसे वह पढ़ नहीं सकता, वह उसे pgp-mime चिह्नित करता है और एक वास्तविक multipart/encrypted संदेश बनाता है। पढ़ना उसी तरह उलटा चलता है: ciphertext लाया जाता है, tab में डिक्रिप्ट होता है, और सामान्य मेल की तरह प्रस्तुत होता है।
एल्गोरिदम वही है जो बाक़ी सब पहले से इस्तेमाल करते हैं: OpenPGP, openpgp.js के ज़रिये, और तार पर PGP/MIME। Curve25519 पर एक v4 कुंजी, वही आकार जो Proton जारी करता है और gpg अपने डिफ़ॉल्ट आधुनिक एल्गोरिदम से बनाता है। इसलिए यह जो मेल पढ़ता है वह सैद्धांतिक रूप से वही मेल है जो Thunderbird, gpg और Proton बनाते हैं, और यहाँ कुछ भी हमारा अपना ऐसा स्वरूप नहीं है जिसे बाद में खोलना पड़े।
व्यवहार में, हालाँकि, यह OpenEmail से OpenEmail तक ही है। इस codebase में कहीं कोई Web Key Directory, कोई keyserver lookup और कोई Autocrypt header पार्सिंग नहीं है: प्राप्तकर्ता की कुंजी केवल हमारी अपनी directory में मिलती है, जिसमें इसी ऐप से उन लोगों द्वारा प्रकाशित कुंजियाँ रहती हैं जिनका address यहाँ होस्ट किए किसी domain पर है। अपनी कुंजी बाँटने का भी कोई तरीक़ा नहीं है। ऐप आपका सार्वजनिक आधा उसी directory में प्रकाशित करता है और उसकी कोई प्रति या export नहीं देता, इसलिए Thunderbird पर बैठे किसी संवाददाता के पास उसे पाने का कोई समर्थित तरीक़ा नहीं है। व्यापक PGP दुनिया से अंतर-संचालन स्वरूप का गुण है, ऐसा कुछ नहीं जो उत्पाद अभी आपके लिए करता हो।
पढ़ना इस तरह सीमित नहीं है, क्योंकि डिक्रिप्शन को directory की ज़रूरत नहीं। कोई भी PGP/MIME या inline-PGP संदेश जो इस mailbox तक इस browser की किसी कुंजी के लिए सील होकर पहुँचता है, खुल जाता है, चाहे उसे किसी ने भी और किसी भी client से भेजा हो। इसमें वे संदेश भी शामिल हैं जो उस कुंजी के लिए सील थे जिसे आप बाद में बदल चुके हैं: सेवानिवृत्त कुंजियाँ keyring में बनी रहती हैं और मौजूदा कुंजी के साथ आज़माई जाती हैं, इसलिए कुंजी बदलने से पहले मिली मेल नहीं खोती।
हरा का अर्थ है खुल गया, और वहाँ किसी और रास्ते से नहीं पहुँचा जा सकता। Details → Security पंक्ति तभी हरी होती है जब इस tab में किसी डिक्रिप्ट ने सचमुच plaintext लौटाया हो, कभी संदेश के किसी field से नहीं, कभी इस तथ्य से नहीं कि कोई एन्क्रिप्टेड envelope आया था। उस पर लिखा होता है “सिरे-से-सिरे तक एन्क्रिप्टेड। इस browser में आपकी कुंजी से खोला गया”। इससे कम हर स्थिति का अपना वाक्य है, साझा नहीं: अभी देख रहे हैं, कुंजी लॉक है, ऐसी कुंजी के लिए सील है जो इस browser के पास नहीं, खोला नहीं जा सका, यहाँ कोई कुंजी है ही नहीं, और इस browser ने हमें देखने नहीं दिया। “हम जाँच नहीं सके” और “आपके पास कुंजी नहीं है” अलग कथन हैं और पंक्ति आपसे पढ़वाती है कि आपको कौन-सा मिला।
S/MIME अब भी नहीं खोला जा सकता। वह X.509 प्रमाणपत्र के नीचे CMS है, openpgp.js उसे छू नहीं सकता, और अगर छू भी सकता तो कुंजी रखने के लिए उत्पाद में कोई certificate store नहीं है, इसलिए S/MIME संदेश कहता है कि OpenEmail उसे नहीं खोल सकता, और उसे ऐसा unlock पेश नहीं किया जाता जो कुछ करता ही नहीं।
निजी आधा आपके browser में बनता है और उसे कभी नहीं छोड़ता: न एन्क्रिप्टेड रूप में, न किसी बैकअप के भीतर, न किसी सहायता उपकरण में। server को वह कभी नहीं भेजा जाता, इसलिए यहाँ सौंपने, subpoena करने या लीक होने को कुछ है ही नहीं। वह passphrase से लॉक होकर अपने ही IndexedDB database, openemail-keyring, में रखा जाता है, जानबूझकर “अपना cache साफ़ करें” वाली सलाह और debug console के reset की पहुँच से बाहर: दोनों query cache मिटाते हैं, और उसके साथ रखी कुंजी साधारण सहायता सलाह को खाते की हर एन्क्रिप्टेड मेल हमेशा के लिए नष्ट करने वाली बना देती। खाता हटाने से वह ज़रूर हट जाती है, क्योंकि वहाँ मेल भी जा रही है। उसे unlock करने पर वह 15 मिनट की निष्क्रियता तक और अधिकतम 8 घंटे तक स्मृति में रहती है, उसके बाद अगला सीलबंद संदेश पढ़ने पर फिर से passphrase माँगी जाती है।
न कोई escrow है और न कोई recovery, और यह अधूरा नहीं बल्कि स्थायी है। आपकी passphrase ही अंदर जाने का अकेला रास्ता है; उसे भूल जाइए और आपके लिए किसी ने भी जो संदेश सील किए वे हमारे servers पर ऐसे ciphertext बने रहेंगे जिन्हें कोई नहीं पढ़ सकता, हम भी नहीं। मेल चली गई, और कितना भी माँगने से वह वापस नहीं आती। नामांकन स्क्रीन पहली कुंजी बनने से पहले ही यह बताती है, एक checkbox के पीछे जिसे आपको टिक करना होता है, और बैकअप फ़ाइल अनिवार्य है, तथा जब तक आप उसे डाउनलोड न कर लें Done बटन निष्क्रिय रहता है। वह फ़ाइल जानबूझकर उस अतिरिक्त at-rest सख़्ती के बिना लिखी जाती है जो यह browser इस्तेमाल करता है, ताकि वह पुराने gpg builds में भी import हो सके: जो बैकअप आप कहीं और खोल न सकें, वह बैकअप नहीं है। कुंजी एक उपकरण के एक browser में ही रहती है, और जब तक आप वह फ़ाइल वहाँ import न करें, फ़ोन या दूसरे लैपटॉप के पास कुछ नहीं होता।
directory केवल सार्वजनिक कुंजियाँ रखती है और कुछ नहीं, और कुंजी किसी mailbox की नहीं, व्यक्ति की होती है, क्योंकि address से जुड़ी कुंजी को उन सबके बीच नक़ल करना पड़ता जिनके साथ वह address साझा है, जो दूसरे नाम का escrow है। किसी को देखने के लिए साइन-इन session और भेजने की अनुमति चाहिए, कोई सार्वजनिक endpoint कभी नहीं, क्योंकि खुली address जाँच एक oracle है जो किसी को भी बता देती है कि यहाँ कौन-से address जीवित mailbox हैं। वह “हम उसे होस्ट नहीं करते” और “हम उसे होस्ट करते हैं पर किसी ने कुंजी प्रकाशित नहीं की” दोनों का एक जैसा उत्तर देती है, क्योंकि इन्हें अलग बताना oracle को हटाता नहीं, बस उसे login के पीछे खिसका देता है। और कुंजी बाँटना उसी क्षण रुक जाता है जब उसका मालिक उस address तक पहुँच खो देता है, न कि तब जब किसी को उसे रद्द करना याद आता है।
हर byte browser में उसी क्षण सील होता है जब आप उसे लिखते हैं, और यही देर से भेजने को संभव बनाता है: निर्धारित संदेश या undo खिड़की में बैठा संदेश ciphertext के रूप में संग्रहित होता है और बाद में उस queue द्वारा भेजा जाता है जिसके पास कोई कुंजी नहीं और जो उसमें से कुछ नहीं पढ़ सकती। जिस प्राप्तकर्ता का directory lookup विफल हुआ, उसे चुपचाप बिना कुंजी वाला मानने के बजाय भेजना रोक दिया जाता है। और सीलबंद संदेश हमेशा केवल उसी रास्ते से जाता है जो संदेश को पूरा ले जाता है। जो बाहर जाने वाला पथ इसके बजाय HTML body लेता है, वह armor को दिखने वाले पाठ के रूप में भेज देता और सफलता की रिपोर्ट देता, इसलिए वहाँ पहुँचने वाला send एक byte निकलने के बाद नहीं, पहले ही ठुकरा दिया जाता है।
सील करने की क़ीमत क्या होगी, अनुमान नहीं बल्कि माप: armor कच्चे bytes का लगभग 1.86 गुना होता है, इसलिए भेजने का पथ जो 5 MB देता है उसमें लगभग 2.7 MB attachments समाते हैं, और composer इससे बड़े payload को एन्क्रिप्ट करने में सेकंड लगाने से पहले ही मना कर देता है, क्योंकि transport उसे वैसे भी ठुकरा देता। एन्क्रिप्टेड मेल कोई open और कोई click रिपोर्ट नहीं करती, क्योंकि प्रति-प्राप्तकर्ता tracking body को हर व्यक्ति के लिए अलग करके चलती है और ciphertext का एक ब्लॉक अलग हो ही नहीं सकता, और फिर से लिखा गया लिंक वह लिंक है जिसे हम पढ़ सकते हैं, जो इस दावे के ठीक उलट है। एन्क्रिप्टेड send को idempotency key से dedupe भी कभी नहीं किया जा सकता: हर प्रयास पर नया session key ciphertext के bytes बदल देता है, इसलिए कोई retry अपने मूल जैसा fingerprint कभी नहीं बनाता।
Scheduling भेजने के समय नहीं, लिखने के समय सील करती है। composer ciphertext उन कुंजियों के विरुद्ध बनाता है जो उसके प्राप्तकर्ताओं के पास उस दिन हैं जिस दिन आप लिखते हैं, उस दिन नहीं जब संदेश निकलेगा — यही नियम यह उत्पाद templates और अनुवादों पर पहले से लागू करता है, जहाँ निर्धारित संदेश वही ले जाता है जिसे आपने मंज़ूर किया था, न कि जो बाद में बदल गया। अंतर यह है कि पुराना template बस बासी होता है जबकि पुरानी कुंजी अपठनीय, इसलिए composer चेतावनी देने के बजाय तिथि शब्दों में बताता है: “अभी सील किया गया, … को भेजा जाएगा। इस पर मौजूद हर व्यक्ति को वही कुंजी चाहिए होगी जो आज उसके पास है।” दूसरे आधे की रक्षा करने वाला इनकार लागू तो है पर कभी चला नहीं, क्योंकि अभी ऐसा कोई संदेश हो ही नहीं सकता: अगर होता, तो बाद में उसे संपादित करने से चुपचाप अनुमति देने के बजाय इनकार होता, क्योंकि body को patch करने का मतलब ciphertext पर plaintext लिखना है और प्राप्तकर्ता बदलने का मतलब यह बदलना है कि वह किसके लिए सील हुआ था, और इनमें से कोई भी उसे खुले रूप में पहुँचा देता जबकि हर स्क्रीन उसे एन्क्रिप्टेड कहती रहती।
दो चीज़ें composer पेश ही नहीं करेगा, और तार पर विफल होने के बजाय यह कह देता है। template server पर किसी प्रकाशित संस्करण से प्रस्तुत होता है, इसलिए इस browser में सील करने को कुछ है ही नहीं। उत्तर अपने नीचे बातचीत उद्धृत करता है और वह उद्धरण body के सील होने के बाद जोड़ा जाता है, जिससे पूरे thread की पठनीय प्रति seal के बाहर बैठी रह जाती, इसलिए जब तक उद्धृत इतिहास ciphertext के भीतर न मोड़ा जाए, उत्तर और अग्रेषण एन्क्रिप्ट नहीं किए जा सकते।
इनमें से कुछ भी आपकी subject पंक्ति, आपने किसे लिखा, या कब लिखा, यह नहीं छिपाता। सीलबंद संदेश पर subject उतने ही खुले रूप में चलता है जितना किसी और संदेश पर, और reading pane संदेश पर ही यह कहता है: “subject और addresses खुले रूप में गए; यह पाठ नहीं गया।” PGP body को ढकता है और उसका कोई भी कार्यान्वयन बाक़ी को नहीं ढकता। Drafts भी बिना सील के हैं, क्योंकि लिखते समय autosave आपके mailbox में plaintext लिखता रहता है, क्योंकि चुपचाप सहेजना बंद कर देने से काम खो जाता, और padlock इसे शब्दों में बता देता है।
सीलबंद आने वाली मेल को पहचानना पहले आया और अब भी क़ायम है। PGP/MIME, inline PGP armor और S/MIME पहले खाली body और दो अर्थहीन attachments के रूप में दिखते थे, क्योंकि parser केवल सादे पाठ और HTML को पठनीय मानता है और बाक़ी को फ़ाइल पट्टी में डाल देता था। अब वे हिस्से पहचाने जाते हैं, protocol का साज़-सामान attachment सूची से बाहर रखा जाता है, ciphertext अक्षत संग्रहित होता है, जिससे reader कुछ नया लाने के बजाय डिक्रिप्ट करता है, और जिस संदेश को यहाँ कोई नहीं खोल सकता, वह यह साफ़ कह भी देता है।
हस्ताक्षरित संदेश को अलग चीज़ माना जाता है, क्योंकि वह है भी। उसका body पठनीय होता है, इसलिए खोज, rules और बाक़ी सब उस पर चलते रहते हैं; उसे कभी ताले के पीछे नहीं रखा जाता और कभी डिक्रिप्ट से नहीं गुज़ारा जाता। पंक्ति धुँधली होकर बताती है “प्रेषक द्वारा हस्ताक्षरित। हस्ताक्षर जाँचा नहीं गया”, और तब तक धुँधली रहती है जब तक यहाँ कुछ वाकई हस्ताक्षर सत्यापित न कर सके, जो अभी कुछ भी नहीं करता, उस संदेश पर भी नहीं जो सफलतापूर्वक डिक्रिप्ट हुआ। यह देखना कि संदेश सीलबंद है, उसे खोल लेने के बराबर नहीं, और उसे खोलना यह जान लेने के बराबर नहीं कि उसे सील किसने किया।
एन्क्रिप्टेड संदेश पर body उन सबसे रोक लिया जाता है जो वरना उसे पढ़ते: खोज का अंश, phishing स्कोरर का body पास, AI-लेखन जाँच, rules में body शर्तें, कैलेंडर आमंत्रण का आयात, और thread सारांश। phishing जाँच का प्रमाणीकरण वाला आधा फिर भी चलता है, क्योंकि DMARC, DKIM और SPF उन headers से पढ़े जाते हैं जिन्हें ciphertext नहीं छिपाता। डिक्रिप्ट करने से इसमें कुछ नहीं बदलता। plaintext केवल उसी tab में होता है जिसने उसे खोला, इसलिए सीलबंद संदेश आपके पढ़ लेने के बाद भी खोजा नहीं जा सकता और AI सुविधाओं से बाहर रहता है, और उस पर अनुवाद पेश नहीं किया जाता। यह दावे की क़ीमत है, कोई चूक नहीं।