🈺 🤾🏽 ✉️ और भी गुप्त टेलीग्राम 👩🏿 ⛔️ 🚴🏻

हम टेलीग्राम को किसी भी प्रकार के संदेशों के लिए विश्वसनीय और सुरक्षित प्रसारण माध्यम मानते थे। लेकिन हुड के तहत, इसमें एक - और सममित एनक्रिप्शन का सामान्य संयोजन है। उसमे मज़ा कहाँ है? और वैसे भी, कोई भी तीसरे पक्ष को अपने संदेशों पर भरोसा क्यों करेगा?
एंटोनियो प्रोहियास द्वारा जासूस बनाम जासूस
TL; DR - एक दूसरे को अवरुद्ध करने वाले उपयोगकर्ताओं पर एक निजी गुप्त चैनल का आविष्कार करना।

गुप्त चैनल

सीधे संपर्क से बचने वाले दो उपयोगकर्ताओं के बीच डेटा संचारित करने के लिए कई वर्कअराउंड हैं। आप बिचौलियों, क्रिप्टो और स्टेग्नोग्राफ़ी विधियों, रिले नेटवर्क का प्रसारण, और मौजूदा प्रोटोकॉल के अन्य एक्सटेंशन का उपयोग कर सकते हैं। लेकिन कभी-कभी यह केवल आधिकारिक रूप से प्रलेखित सुविधाओं का उपयोग करके सुरक्षित संपर्क स्थापित करने में सक्षम होता है। या जैसा कि एक को कहना चाहिए, एक गुप्त चैनल स्थापित करें।

हम इसका एक उदाहरण एक सोवियत जासूसी फिल्म "सत्रह क्षणों का वसंत" में देख सकते हैं (यह एक है, जैसे, वास्तव में अच्छा है, इसे देखने की कोशिश करें)। इसमें, सुरक्षित घर की खिड़की में एक फूल को संकेत देने के लिए इस्तेमाल किया गया था कि क्या जासूस अपने मिशन में विफल रहा था या नहीं। अपने आप से फूल का कोई मतलब नहीं है: यह वहां हो सकता है और नहीं हो सकता है, इस तरह के सहजीवन एक सामान्य बात है और केवल हमें फूलों के लिए मालिक के प्यार के बारे में बता रहे हैं। केवल एक पूर्व निर्धारित व्याख्या एक यादृच्छिक राहगीर द्वारा प्राप्त एक जासूस से प्राप्त जानकारी को अलग करती है।

फिल्म से

टेलीग्राम में इन-विंडो फ्लावर-आधारित चैनल

एक ही सिद्धांत द्वारा अपने स्वयं के गुप्त चैनल को व्यवस्थित करने के लिए आपको केवल दो चीजों की आवश्यकता होगी: एक खिड़की और एक फूल। खिड़की एक वस्तु का प्रतिनिधित्व करती है जिसे आप दूसरों द्वारा देखे जाने की स्थिति और फूल - संभव स्थिति और उन्हें बदलने का एक तरीका बदल सकते हैं।

तो ऐलिस टेलीग्राम में क्या बदल सकता है जो बॉब देख सकता है? कई चीजें, वास्तव में: अवतार, उपयोगकर्ता नाम, पिछली बार का दौरा किया और अधिक। लेकिन आमतौर पर, ये चीजें एक ही समय में सभी के लिए उपलब्ध हैं, संवाद गोपनीयता को सीमित करते हुए - यदि कोई संक्रमण विधि रखता है, तो वह ऐलिस सेंड्स पढ़ सकता है। आश्चर्यजनक रूप से, इस सीमा के आसपास किसी भी तरह के एन्क्रिप्शन को शामिल किए बिना संभव है।

मैं तुम्हें रोक रहा हूं, हाहा

प्रत्येक उपयोगकर्ता की अपनी काली सूची होती है, और यदि पाठक काफी परेशान हो रहा था, तो उसे अवरुद्ध होने के बाद ध्यान देना चाहिए कि उसके पहले से ही एक दोस्त से 'अंतिम बार' स्थिति बदलकर 'अंतिम बार एक लंबे समय से पहले देखी गई' थी। सच्चाई यह है कि, वह कुछ सेकंड पहले ऑनलाइन हो सकता था या अभी हो सकता है, लेकिन टेलीग्राम एपीआई इस जानकारी को आपके ऐप पर अब नहीं भेजेगा। इस तरह, यह अन्य उपयोगकर्ता की गोपनीयता को अवांछित लोगों से बचा रहा है। बदले में, वे देख सकते हैं कि क्या उन्हें ब्लैकलिस्ट किया गया है या नहीं।

तो क्या एक फूल देख रहे हैं और सामान्य रूप से अवरुद्ध किया जा रहा है? दोनों को एक निश्चित समय पर चेक किया जा सकता है, यदि आप अवरुद्ध हैं या नहीं, इसके आधार पर एक बिट जानकारी प्राप्त करने की अनुमति है। एक अन्य लाभ यह तथ्य है कि टेलीग्राम शायद एक-दूसरे को अवरुद्ध करने वाले उपयोगकर्ताओं के लॉग को स्टोर नहीं करता (कम से कम जर्नलिंग उद्देश्यों के लिए)।

बिट्स का आयोजन

बिट्स भेजने और प्राप्त करने की संभावना मजेदार और सभी है, लेकिन हमें अभी भी इसके शोषण तंत्र का वर्णन करने की आवश्यकता है। टेलीग्राम अवरुद्ध होने पर आपको नोटिस करने से इनकार करता है, इसलिए प्रत्येक 'प्राप्त बिट' कार्रवाई प्राप्तकर्ता द्वारा शुरू की जानी चाहिए (चलो उसे बॉब कहते हैं) और प्रेषक (और वह ऐलिस होगा) पर निर्भर करता है, अर्थात स्वतंत्र द्वारा। यह भी इस प्रकार है कि ऐलिस और बॉब को एक ही आवृत्ति पर अनुरोध करना चाहिए।

प्रत्येक घड़ी पर बिट एक्सचेंज एल्गोरिथ्म इस तरह दिखता है:

एक बिट भेजने वाला चेक और अगर पिछले मूल्य से भिन्न है तो यह एक मूल्य के आधार पर बदल सकता है:
- ए -> टी: ब्लॉक बी अगर बिट 1 है;
- A -> T: अगर B 0 है तो अनब्लॉक करें।
B एक सा प्राप्त करता है:
- बी -> टी: ए का समाधान;
- टी -> बी: ए के बारे में बी जानकारी के लिए उपलब्ध;
- बी: जाँच करता है कि क्या प्राप्त जानकारी की स्थिति है:
  - बी: अगर यह है -> वह अवरुद्ध नहीं है और बिट 0 है
  - बी: अगर यह नहीं है -> वह अवरुद्ध है और बिट 1 है

अधिकांश आधुनिक पीसी में अच्छी आवृत्ति जनरेटर (उदाहरण के लिए एक सिस्टम क्लॉक) होता है, इसलिए हम संदेश बिट्स को छोड़कर कुछ भी प्रसारित करने के लिए चैनल का उपयोग नहीं करते हुए अपनी घड़ियों को उनके साथ सिंक्रनाइज़ कर सकते हैं। केवल यह ध्यान देने योग्य है कि टेलीग्राम एपीआई अनुरोध, दोनों (संयुक्त राष्ट्र) अवरुद्ध और उपयोगकर्ता की स्थिति को हल कर रहे हैं, नेटवर्क कॉल हैं और जल्दी से काम नहीं करते हैं, खासकर यदि आप प्रॉक्सी या वीपीएन का उपयोग कर रहे हैं। यह एक सीमा पैदा करता है: घड़ी की लंबाई औसत प्रतिक्रिया समय की तुलना में लंबी होनी चाहिए (क्योंकि हमें एक दूसरे में फिट होने की आवश्यकता है) और यही कारण है कि हमारे डेटा ट्रांसमिशन की गति सीमित होगी।

संदेश एन्कोडिंग

प्राकृतिक भाषाओं में ग्रंथों में बहुत अधिक अतिरेक होता है, और त्रुटियों के साथ प्राप्त संदेश अभी भी ज्यादातर मानव द्वारा पठनीय होंगे। और जब से टेलीग्राम एक संदेशवाहक है (कुछ पागल सामान की अनदेखी), हम त्रुटि सुधार को सरल पाठ संदेश में संभव संचारित डेटा को सीमित करने की उपेक्षा कर सकते हैं।

हमारे चैनल में बेहद कम बैंडविड्थ है, इसलिए हमें संभावित संदेशों के लिए उपलब्ध सबसे प्रभावी संदेश एन्कोडिंग का उपयोग करने की आवश्यकता है। हमारे लिए भाग्यशाली, संदेशवाहक का नाम कई बार याद दिलाता है कि ऐसी समस्या आम थी।

यही कारण है कि हम, 21 वीं सदी में रह रहे हैं, हमारे ग्रंथों को एक सौ साल पहले एनकोडिंग - बॉडोट कोड - टेलीग्राफर्स के लिए सबसे कुशल उपलब्ध में से एक के साथ कूटबद्ध करेंगे। अधिक सटीक रूप से, इसकी अंतिम भिन्नता ITA-2 डोनाल्ड मुर्रे द्वारा बनाई गई, जो भाषा के सबसे लगातार प्रतीकों पर कम एपीआई कॉल करने के लिए है।

एक संदेश को सफलतापूर्वक प्रसारित करने के लिए केवल एक संचरण सत्र की सीमाओं को खोजने के लिए छोड़ दिया जाता है, ताकि प्राप्तकर्ता को निरंतर बिट स्ट्रीम के बीच एक भेजा जा सके। ट्रांसमिशन शुरू होने से पहले, बॉब या तो अवरुद्ध है या नहीं, और उसका राज्य कभी भी जल्द ही अपने आप से नहीं बदल रहा है। यही कारण है कि एलिस केवल एक घड़ी के लिए विपरीत दिशा में स्वैप करके सत्र की शुरुआत के बारे में संकेत दे सकता है। सत्र के सफल अंत में, वह उसे अनब्लॉक करेगी और शांति के साथ छोड़ देगी। वह, दूसरी तरफ, शून्य बिट्स प्राप्त करना जारी रखेगा जब तक वे यह तय नहीं कर लेते कि वे संदेश का हिस्सा नहीं हैं - बॉडोट कोड का कोई 00000 प्रतीक नहीं है।

समय पर

विधि की कमियां कनेक्ट करने के लिए एक व्यावहारिक अक्षमता है (आप कर सकते हैं, लेकिन यह संभवतः बिट शिफ्ट के कारण मैन्युअल त्रुटि सुधार की आवश्यकता होगी) चल रहे अनुवाद के लिए और लोगों से त्रुटियों के साथ प्राप्त अशक्त प्रतीकों को अलग करने की आवश्यकता है। लेकिन कार्यान्वयन की सभी समस्याएं हैं।

उच्च तकनीक

कई घंटों के बाद एपीआई का उपयोग करने के लिए एक आधिकारिक पुस्तकालय का उपयोग करने की कोशिश कर रहा था, मैं थक गया और अधिक मानव-अनुकूल टेलीथॉन पुस्तकालय का उपयोग करके अजगर के साथ सब कुछ लिखा। यहां तक कि कुछ दुर्लभ कारणों के लिए आज भी एक तुल्यकालिक शैली एपीआई है। ITA-2 के साथ मैसेज एन्कोडिंग मैंने खुद से लिखी है क्योंकि मुझे इंटरनेट पर कुछ भी उपयोगी नहीं मिला है।

सिस्टम क्लॉक (और हाँ, यह सो जाओ!) के बीच में बनाया गया क्लॉक सिंक्रोनाइज़ेशन क्योंकि यह हर नेटवर्क एपीआई कॉल पर आवश्यक समय को ध्यान में रखते हुए सटीक है, ज्यादातर मामलों में यह एक सेकंड के दसवें हिस्से से अधिक है। उपयोगकर्ता संचरण की गति निर्धारित कर सकता है क्योंकि वह चाहता है, लेकिन मैं 'प्रति सेकंड के अनुरोध से अधिक नहीं' नियम का पालन करने की सलाह देता हूं यदि आप दोनों दूसरी तरफ त्रुटियों को नहीं देखना चाहते हैं और अपने आप को बाढ़ रोकथाम प्रणाली द्वारा प्रतिबंधित पाते हैं। टेलीग्राम एपीआई उपयोग को लेकर बहुत चुस्त-दुरूस्त था, एक दिन के लिए मेरी पहुँच को कुछ सरल (सफल!) से भी मुक्त कर देता है। प्राधिकरण के प्रयास एक पंक्ति में और अनजान कारण से प्रसारण के दौरान बाढ़ के लिए बस बेतरतीब अवरुद्ध हो जाते हैं। आपको हमेशा अपनी एपीआई उपयोग की सीमाएँ, दोस्तों की घोषणा करनी चाहिए।

यदि उपयोगकर्ता संदेशों का आदान-प्रदान करने के लिए इस तरह के अजीब चैनल का उपयोग करने का निर्णय लेता है, तो उसे किसी भी ग्राफिकल यूजर इंटरफेस सुविधाओं की परवाह नहीं करनी चाहिए। और सभी प्रणालियों के पास वैसे भी नहीं है, इसीलिए मैंने अपना आवेदन टर्मिनल टूल के रूप में लिखा है। यह कमांड-लाइन तर्कों उपयोगकर्ता आईडी में दिए गए एक चैनल के माध्यम से संदेश भेजने और प्राप्त करने की अनुमति देता है, लेकिन प्रति लॉन्च केवल एक ऑपरेशन। बेशक, कोई भी आपको किसी कार्यक्रम की केवल एक प्रति चलाने के लिए सीमित नहीं करेगा और दोनों तरीकों से एक साथ कई चैनलों का उपयोग करेगा, आपको बस एक ही स्क्रिप्ट की कई प्रतियाँ विभिन्न मापदंडों के साथ चलाने की आवश्यकता होगी।

सामान का उपयोग करना

आप इस चीज़ को कमांड-लाइन यूटिलिटी और python3 लाइब्रेरी दोनों के रूप में GitHub पर एपीआई के माध्यम से पढ़ सकते हैं। एकमात्र समस्या यह है कि आपके स्वयं के एपीआई क्रेडेंशियल्स (सरल मैनुअल पर्याप्त सहायक है) प्राप्त करने के बाद से टेलीग्राम मुझे एक स्क्रिप्ट की आपकी स्थानीय प्रति में मान के अनुसार खुलासा करने और सेट करने की अनुमति नहीं देता है। सब कुछ कमांड लाइन के तर्कों के माध्यम से पारित हो गया जो प्राधिकरण भाग को छोड़कर जो डिफ़ॉल्ट रूप से stdio के माध्यम से बनाया गया है) और इस तरह दिखता है:

 For Alice: For Bob: Enter your phone number: XXX | Enter your phone number: XXX Enter auth code: YYY | Enter auth code: YYY Started message transmission... | Listening for the message... ---++ ('O', '9') | ---++ ('O', '9') --+-+ ('H', '#') | --+-+ ('H', '#') +++++ (1, 1) | +++++ (1, 1) --++- ('N', ',') | --++- ('N', ',') --+-- (' ', ' ') | --+-- (' ', ' ') ++-++ (0, 0) | ++-++ (0, 0) --+-+ ('H', '#') | --+-+ ('H', '#') -++-- ('I', '8') | -++-- ('I', '8') --+-- (' ', ' ') | --+-- (' ', ' ') --+++ ('M', '.') | --+++ ('M', '.') ++--- ('A', '-') | ++--- ('A', '-') -+-+- ('R', "'") | -+-+- ('R', "'") ++++- ('K', '(') | ++++- ('K', '(') +++++ (1, 1) | +++++ (1, 1) +-++- ('F', '!') | +-++- ('F', '!') --+++ ('M', '.') | --+++ ('M', '.') --+++ ('M', '.') | --+++ ('M', '.') Done, exiting... | ----- ('', '') | ----- ('', '') | Automatically decoded: OH, HI MARK!..

प्राप्त संदेश स्वचालित रूप से डिकोड हो जाता है, लेकिन यदि आप मैन्युअल रूप से कुछ त्रुटियों को ठीक करना चाहते हैं या प्रगति को ट्रैक करना चाहते हैं, तो क्या यह कमांड लाइन आउटपुट को देख सकता है।

तार के बाहर

ध्यान देने योग्य बात यह है कि इस तरह के चैनल को किसी भी मैसेंजर और / या सोशल नेटवर्क पर लागू किया जा सकता है जिसमें कोई अन्य उपयोगकर्ताओं द्वारा ब्लॉक किए जाने या न होने का पता लगा सकता है। मौजूदा कोड में समान इंटरफेस को आसानी से बदला जा सकता है, इसलिए यदि आप इसे करना चाहते हैं, तो बस मेरा ग्राउंडवर्क का उपयोग करें। कम संचरण गति और एपीआई कॉल प्रतिक्रिया समय के कारण कम पायथन का प्रदर्शन (ऐसी चीजों के लिए सामान्य रूप से C / ++ की तुलना में) सीमित कारक नहीं होगा।

PS मुझे अवरुद्ध करने के लिए मेरे जुनून के असामान्य प्यार के लिए विशेष धन्यवाद

और भी गुप्त टेलीग्राम