नमस्ते दोस्तों, ये रहे हमारे cough साप्ताहिक स्टेटस नोट्स
- Index:
- 0.6.1.25 और नेट स्थिति 2) I2PSnark 3) Syndie (क्या/क्यों/कब) 4) Syndie क्रिप्टोग्राफी संबंधी प्रश्न 5) ???
- 0.6.1.25 and net status
कुछ दिन पहले हमने 0.6.1.25 रिलीज़ जारी की, जिसमें पिछले महीने के दौरान एकत्र हुए कई बग फिक्स शामिल थे, साथ ही I2PSnark पर zzz का काम और हमारे समय समन्वय कोड को थोड़ा अधिक मजबूत बनाने के लिए Complication का काम भी था। अभी नेटवर्क काफ़ी स्थिर दिख रहा है, हालांकि पिछले कुछ दिनों में IRC थोड़ा समस्याग्रस्त रहा है (I2P से असंबंधित कारणों के चलते)। संभवतः नेटवर्क का लगभग आधा हिस्सा नवीनतम रिलीज़ में अपग्रेड हो चुका है, फिर भी tunnel निर्माण की सफलता दर में ज़्यादा बदलाव नहीं आया है, हालांकि समग्र थ्रूपुट बढ़ा हुआ लगता है (संभवतः I2PSnark का उपयोग करने वाले लोगों की संख्या में बढ़ोतरी के कारण)।
- I2PSnark
zzz द्वारा I2PSnark में किए गए अपडेट में प्रोटोकॉल अनुकूलन के साथ-साथ वेब इंटरफेस में बदलाव भी शामिल थे, जैसा कि इतिहास लॉग [1] में वर्णित है। 0.6.1.25 रिलीज़ के बाद से I2PSnark के लिए कुछ छोटे अपडेट भी हुए हैं, और शायद zzz आज रात की बैठक के दौरान हमें यह बताने के लिए एक सिंहावलोकन दे सकते हैं कि क्या चल रहा है।
[1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD
- Syndie
जैसा कि आप सभी जानते हैं, मेरा समय Syndie के पुनर्निर्माण पर केंद्रित रहा है, हालांकि “revamp” शायद सही शब्द नहीं है। शायद आप जो वर्तमान में परिनियोजित है, उसे “proof of concept” (संकल्पना का प्रमाण) मान सकते हैं, क्योंकि नई Syndie को शुरुआत से फिर से डिज़ाइन किया गया है और पुनः कार्यान्वित किया गया है, हालांकि कई अवधारणाएँ बनी हुई हैं। नीचे जब मैं Syndie का उल्लेख करता हूँ, तो मेरा मतलब नई Syndie से है।
- 3.1) What is Syndie
Syndie अपने सबसे बुनियादी स्तर पर ऑफलाइन वितरित फोरम संचालित करने के लिए एक प्रणाली है। इसकी संरचना अनेक भिन्न कॉन्फ़िगरेशन तक ले जाती है, लेकिन अधिकांश आवश्यकताएँ निम्नलिखित तीन मानदंडों में से प्रत्येक से एक विकल्प चुनने पर पूरी हो जाएँगी: - फोरम प्रकार: - एकल लेखक (सामान्य ब्लॉग) - एकाधिक लेखक (बहु-लेखक ब्लॉग)** - खुला (न्यूज़ग्रुप्स, हालाँकि ऐसे प्रतिबंध शामिल किए जा सकते हैं ताकि केवल अधिकृत** उपयोगकर्ता नई थ्रेड्स पोस्ट कर सकें, जबकि कोई भी उन नई थ्रेड्स पर टिप्पणी कर सकता है) - दृश्यता: - कोई भी सब कुछ पढ़ सकता है - केवल अधिकृत* लोग पोस्ट पढ़ सकते हैं, लेकिन कुछ मेटाडेटा उजागर होता है - केवल अधिकृत* लोग पोस्ट पढ़ सकते हैं, या यहाँ तक कि यह जान सकते हैं कि कौन पोस्ट कर रहा है - केवल अधिकृत* लोग पोस्ट पढ़ सकते हैं, और कोई नहीं जानता कि कौन पोस्ट कर रहा है - टिप्पणियाँ/उत्तर: - कोई भी लेखक/फोरम मालिक को टिप्पणी कर सकता है या निजी उत्तर भेज सकता है - केवल अधिकृत** लोग टिप्पणी कर सकते हैं, और कोई भी निजी उत्तर भेज सकता है - कोई भी टिप्पणी नहीं कर सकता, लेकिन कोई भी निजी उत्तर भेज सकता है - कोई भी टिप्पणी नहीं कर सकता, और कोई भी निजी उत्तर नहीं भेज सकता
- reading is authorized by giving people the symmetric key or passphrase to decrypt the post. Alternately, the post may include a publicly visible prompt, where the correct answer serves to generate the correct decryption key.
** पोस्ट करना, अपडेट करना, और/या टिप्पणी करना इस प्रकार अधिकृत किया जाता है कि उन उपयोगकर्ताओं को पोस्टों पर हस्ताक्षर करने हेतु असिमेट्रिक प्राइवेट कीज़ दी जाती हैं, जहाँ संबंधित पब्लिक की फोरम के मेटाडेटा में फोरम पर पोस्ट करने, प्रबंधित करने, या टिप्पणी करने के लिए अधिकृत के रूप में शामिल होती है। वैकल्पिक रूप से, व्यक्तिगत अधिकृत उपयोगकर्ताओं की साइनिंग पब्लिक कीज़ medtata में सूचीबद्ध की जा सकती हैं।
व्यक्तिगत पोस्ट में कई अलग-अलग तत्व हो सकते हैं: - किसी भी संख्या में पृष्ठ, प्रत्येक पृष्ठ के लिए out of band (मुख्य डेटा प्रवाह से अलग) डेटा जो निर्दिष्ट करता हो सामग्री का प्रकार, भाषा आदि। किसी भी प्रकार का फ़ॉर्मैटिंग उपयोग किया जा सकता है, क्योंकि सामग्री को सुरक्षित रूप से प्रस्तुत करना क्लाइंट एप्लिकेशन पर निर्भर है - साधारण पाठ का समर्थन आवश्यक है, और जो क्लाइंट सक्षम हों उन्हें HTML का भी समर्थन करना चाहिए। - किसी भी संख्या में अटैचमेंट (फिर से, अटैचमेंट का वर्णन करने वाला out of band डेटा) - पोस्ट के लिए एक छोटा अवतार (पर यदि निर्दिष्ट न हो, तो लेखक का डिफ़ॉल्ट अवतार उपयोग किया जाता है) - अन्य पोस्ट, फ़ोरम, आर्काइव, URLs आदि के संदर्भों का एक सेट (जिसमें संदर्भित फ़ोरम पर पोस्ट करने, प्रबंधन करने, या पढ़ने के लिए आवश्यक कुंजियाँ शामिल हो सकती हैं)
कुल मिलाकर, Syndie सामग्री स्तर पर काम करता है - अलग-अलग पोस्ट कूटबद्ध ZIP फ़ाइलों में समाहित होती हैं, और फ़ोरम में भाग लेना बस इन फ़ाइलों को साझा करना है। फ़ाइलों को कैसे स्थानांतरित किया जाता है (I2P, Tor, Freenet, gnutella, bittorrent, RSS, usenet, email के माध्यम से) इस पर कोई निर्भरता नहीं है, लेकिन मानक Syndie रिलीज़ के साथ सरल समेकन और वितरण उपकरण शामिल किए जाएँगे।
Syndie सामग्री के साथ अंतःक्रिया कई तरीकों से होगी। सबसे पहले, एक स्क्रिप्ट करने योग्य पाठ-आधारित इंटरफ़ेस है, जो बुनियादी कमांड-लाइन और इंटरैक्टिव तरीके से फ़ोरम से पढ़ने, उन पर लिखने, प्रबंधन करने और उन्हें समकालित करने की सुविधा देता है। उदाहरण के लिए, निम्नलिखित एक नई “message of the day” (दिन का संदेश) पोस्ट बनाने के लिए एक सरल स्क्रिप्ट है -
login menu post create –channel 0000000000000000000000000000000000000000 addpage –in /etc/motd –content-type text/plain addattachment –in ~/webcam.webp –content-type image/png listauthkeys –authorizedOnly true authenticate 0 authorize 0 set –subject “Today’s MOTD” set –publicTags motd execute exit
बस उसे syndie executable के माध्यम से पाइप कर दें और काम हो गया: cat motd-script | ./syndie > syndie.log
इसके अतिरिक्त, एक ग्राफ़िकल Syndie इंटरफ़ेस पर काम चल रहा है, जिसमें सादा पाठ और HTML पृष्ठों की सुरक्षित रेंडरिंग शामिल है (बिल्कुल, Syndie की विशेषताओं के साथ पारदर्शी एकीकरण का समर्थन भी)।
पुराने Syndie के “sucker” कोड पर आधारित अनुप्रयोग सामान्य वेब पेजों और वेबसाइटों की स्क्रैपिंग और पुनर्लेखन को सक्षम करेंगे, ताकि उन्हें एकल या बहु-पृष्ठ Syndie पोस्ट के रूप में उपयोग किया जा सके, जिनमें छवियाँ और अन्य संसाधन संलग्नकों के रूप में शामिल हों।
आगे चलकर, firefox/mozilla प्लगइन्स की योजना है कि वे Syndie स्वरूपित फ़ाइलों और Syndie संदर्भों का पता लगाएंगी और उन्हें आयात करेंगी, साथ ही स्थानीय Syndie GUI (ग्राफिकल यूज़र इंटरफ़ेस) को यह सूचित करेंगी कि किसी विशेष फ़ोरम, विषय, टैग, लेखक, या खोज परिणाम को फ़ोकस में लाया जाना चाहिए।
बिल्कुल, चूँकि Syndie मूल रूप से एक सामग्री स्तर है जिसमें परिभाषित फ़ाइल प्रारूप और क्रिप्टोग्राफिक एल्गोरिदम हैं, समय के साथ अन्य अनुप्रयोग या वैकल्पिक कार्यान्वयन संभवतः पेश किए जाएँगे।
- 3.2) Why does Syndie matter?
पिछले कुछ महीनों में मैंने कई लोगों को यह पूछते सुना है कि मैं फ़ोरम/ब्लॉगिंग टूल पर क्यों काम कर रहा हूँ — इसका मज़बूत गुमनामी प्रदान करने से क्या संबंध है?
उत्तर: सब कुछ.
संक्षेप में: - Syndie का डिज़ाइन, एक अनामिकता-संवेदी क्लाइंट एप्लिकेशन के रूप में, सावधानीपूर्वक लगभग हर उस एप्लिकेशन में पाई जाने वाली जटिल डेटा-संवेदनशीलता समस्याओं से बचता है जो अनामिकता को ध्यान में रखकर नहीं बनाए गए होते और इसलिए उनसे नहीं बच पाते। - content layer (सामग्री स्तर) पर कार्य करते हुए, Syndie I2P, Tor, या Freenet जैसी वितरित नेटवर्कों के प्रदर्शन या विश्वसनीयता पर निर्भर नहीं करता, हालाँकि उपयुक्त स्थिति में वह उनका लाभ उठा सकता है। - ऐसा करके, यह सामग्री वितरण के छोटे, एड-हॉक तंत्रों के साथ पूरी तरह काम कर सकता है - ऐसे तंत्र जिन्हें निष्प्रभावी करने का प्रयास शक्तिशाली विरोधियों के लिए शायद सार्थक न हो (क्योंकि केवल कुछ दर्जन लोगों को पकड़ने का ‘payoff’ संभवतः हमले शुरू करने की लागत से अधिक होगा) - इससे संकेत मिलता है कि Syndie कुछ मिलियन लोगों के उपयोग के बिना भी उपयोगी रहेगा - एक-दूसरे से असंबंधित छोटे समूहों को किसी भी अन्य समूह के साथ किसी प्रकार की अंतःक्रिया की आवश्यकता के बिना, या उनके बारे में जानकारी होने की आवश्यकता के बिना, अपना निजी Syndie वितरण तंत्र स्थापित करना चाहिए। - चूँकि Syndie रियल-टाइम अंतःक्रिया पर निर्भर नहीं है, यह उच्च विलंबता वाली अनामिकता प्रणालियों और तकनीकों का भी उपयोग कर सकता है ताकि उन हमलों से बचा जा सके जिनके प्रति सभी कम विलंबता वाली प्रणालियाँ संवेदनशील होती हैं (जैसे निष्क्रिय इंटरसेक्शन हमले, निष्क्रिय और सक्रिय टाइमिंग हमले, तथा सक्रिय ब्लेंडिंग हमले)।
कुल मिलाकर, मेरा मानना है कि I2P के मूल मिशन (जिन्हें इसकी आवश्यकता है उन्हें मजबूत गुमनामी प्रदान करना) के संदर्भ में Syndie, router से भी अधिक महत्वपूर्ण है। यह अंतिम और सर्वोपरि चीज़ नहीं है, लेकिन यह एक महत्वपूर्ण कदम है।
- 3.3) When can we use Syndie?
काफ़ी काम पूरा हो चुका है (टेक्स्ट इंटरफ़ेस का लगभग पूरा हिस्सा और GUI (ग्राफिकल यूज़र इंटरफ़ेस) का एक अच्छा हिस्सा शामिल है), फिर भी कुछ काम शेष है। Syndie के पहले रिलीज़ में निम्नलिखित आधारभूत कार्यक्षमताएँ शामिल होंगी:
- Scriptable text interface, packaged up as a typical java application, or buildable with a modern GCJ
- Support for all forum types, replies, comments, etc.
- Manual syndication, transferring .snd files.
- HTTP syndication, including simple CGI scripts to operate archives, controllable through the text interface.
- Specs for the file formats, encryption algorithms, and database schema.
इसे जारी करने के लिए मैं जो मानदंड अपनाऊँगा, वह “पूरी तरह कार्यात्मक” होगा। आम उपयोगकर्ता टेक्स्ट-आधारित ऐप से नहीं उलझेंगे, लेकिन मुझे उम्मीद है कि कुछ गीक्स ऐसा करेंगे।
आगामी संस्करण Syndie की क्षमताओं में कई आयामों में सुधार करेंगे:
- उपयोगकर्ता इंटरफ़ेस:
- SWT-आधारित GUI
- वेब ब्राउज़र प्लगइन्स
- वेब स्क्रेप टेक्स्ट UI (पृष्ठों को लाकर पुनर्लेखन करना)
- IMAP/POP3/NNTP पढ़ने का इंटरफ़ेस
- सामग्री समर्थन
- सादा पाठ
- HTML (GUI के भीतर सुरक्षित रेंडरिंग, ब्राउज़र में नहीं)
- BBCode (?)
- सिंडिकेशन
- Feedspace, Feedtree, और अन्य कम-विलंबता समकालिकरण उपकरण
- Freenet (.snd फ़ाइलों को CHK@s पर संग्रहीत करना और आर्काइव जो SSK@s और USK@s पर .snd फ़ाइलों को संदर्भित करते हैं)
- ईमेल (SMTP/mixmaster/mixminion के माध्यम से पोस्ट करना, पढ़ना procmail/etc के माध्यम से)
- Usenet (NNTP या remailers के माध्यम से पोस्ट करना, पढ़ना (proxied) NNTP के माध्यम से)
- Lucene एकीकरण के साथ पूर्ण-पाठ खोज
- पूर्ण डेटाबेस एन्क्रिप्शन के लिए HSQLDB का विस्तार
- अतिरिक्त आर्काइव प्रबंधन heuristics (अनुमान-आधारित विधियाँ)
किस समय क्या निकलता है, यह इस पर निर्भर करता है कि कार्य कब किए जाते हैं।
- Open questions for Syndie
वर्तमान में, Syndie को I2P के मानक क्रिप्टोग्राफिक प्रिमिटिव्स - SHA256, AES256/CBC, ElGamal2048, DSA - के साथ लागू किया गया है। हालाँकि, अंतिम वाला बेमेल है, क्योंकि यह 1024-बिट सार्वजनिक कुंजियों का उपयोग करता है और (तेज़ी से कमजोर हो रहा) SHA1 पर निर्भर है। फ़ील्ड से मैंने जो एक सुझाव सुना है, वह DSA का SHA256 के साथ संवर्धन है, और जबकि यह संभव है (भले ही अभी मानकीकृत नहीं हुआ है), यह केवल 1024-बिट सार्वजनिक कुंजियाँ ही प्रदान करता है।
चूँकि Syndie को अभी तक सार्वजनिक रूप से जारी नहीं किया गया है, और बैकवर्ड संगतता की कोई चिंता नहीं है, हमारे पास crypto primitives (क्रिप्टोग्राफिक प्रिमिटिव्स) को आपस में बदलने की सुविधा है। एक विचार यह है कि DSA के बजाय ElGamal2048 या RSA2048 हस्ताक्षरों को चुना जाए, जबकि दूसरा विचार ECC (एलिप्टिक कर्व क्रिप्टोग्राफी) की ओर देखना है (ECDSA (एलिप्टिक कर्व डिजिटल सिग्नेचर एल्गोरिथ्म) हस्ताक्षर और ECIES (एलिप्टिक कर्व इंटीग्रेटेड एन्क्रिप्शन स्कीम) asymmetric encryption (असममित एन्क्रिप्शन) के साथ), संभवतः 256-बिट या 521-बिट सुरक्षा स्तरों पर (जो क्रमशः 128-बिट और 256-बिट सममित कुंजी आकारों के अनुरूप हैं)।
ECC से संबंधित पेटेंट मुद्दों के बारे में, वे शायद केवल कुछ विशेष अनुकूलनों (point compression) और उन एल्गोरिद्म पर ही लागू होते हैं जिनकी हमें आवश्यकता नहीं है (EC MQV)। Java समर्थन के संदर्भ में बहुत कुछ उपलब्ध नहीं है, हालांकि bouncycastle lib में कुछ कोड लगता है। फिर भी, libtomcrypt, openssl, या crypto++ में छोटे wrapper (रैपर) जोड़ना भी संभवतः ज्यादा कठिन नहीं होगा, जैसा कि हमने libGMP के लिए किया था (जिससे हमें jbigi मिला)।
क्या इस पर कोई विचार है?
- ???
वहाँ समझने के लिए बहुत कुछ है, इसी वजह से (cervantes के सुझाव पर) मैंने ये स्टेटस नोट्स इतनी जल्दी भेजे हैं। अगर आपके पास कोई टिप्पणियाँ, प्रश्न, चिंताएँ, या सुझाव हों, तो आज रात 8pm UTC पर irc.freenode.net/irc.postman.i2p/irc.freshcoffee.i2p के चैनल #i2p पर हमारी cough साप्ताहिक मीटिंग में शामिल हो जाइए!
=jr