مرحباً يا جماعة، إليكم ملاحظات حالتنا سعال الأسبوعية

  • Index:
  1. 0.6.1.25 وحالة الشبكة 2) I2PSnark 3) Syndie (ما/لماذا/متى) 4) أسئلة التشفير الخاصة بـ Syndie 5) ???
    1. 0.6.1.25 and net status

قبل بضعة أيام أصدرنا الإصدار 0.6.1.25، بما في ذلك كمّ كبير من إصلاحات الأخطاء التي تراكمت خلال الشهر الماضي، وكذلك عمل zzz على I2PSnark وعمل Complication لمحاولة جعل شيفرة مزامنة الوقت لدينا أكثر متانةً قليلًا. حاليًا تبدو الشبكة مستقرة إلى حدٍّ معقول، رغم أن IRC كان مضطربًا قليلًا في الأيام القليلة الماضية (لأسباب غير مرتبطة بـ I2P). ومع ترقية ربما نصف الشبكة إلى أحدث إصدار، لم تتغير معدلات نجاح بناء tunnel كثيرًا، مع أن معدل النقل الإجمالي يبدو أنه قد ارتفع (على الأرجح بسبب زيادة عدد الأشخاص الذين يستخدمون I2PSnark).

    1. I2PSnark

شملت تحديثات zzz على I2PSnark تحسينات على البروتوكول وكذلك تغييرات في واجهات الويب، كما هو موصوف في سجلّ التاريخ [1]. كانت هناك أيضاً بعض التحديثات الصغيرة لـ I2PSnark منذ إصدار 0.6.1.25، وربما يستطيع zzz أن يزوّدنا بنظرة عامة عمّا يجري خلال الاجتماع الليلة.

[1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD

    1. Syndie

كما تعلمون جميعًا، كان تركيزي منصبًا على تجديد Syndie، رغم أن “التجديد” قد لا تكون الكلمة المناسبة. ربما يمكنكم اعتبار ما هو المتاح حاليًا بمثابة “إثبات مفهوم”، لأن 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.

** يتم تخويل النشر والتحديث و/أو التعليق عبر تزويد أولئك المستخدمين بمفاتيح خاصة غير متماثلة لتوقيع المشاركات، حيث يُدرَج المفتاح العام المقابل في البيانات الوصفية للمنتدى بوصفه مخوّلاً للنشر أو الإدارة أو التعليق في المنتدى. بدلاً من ذلك، يمكن إدراج مفاتيح التوقيع العامة للمستخدمين المخوّلين بشكل فردي في البيانات الوصفية.

قد تحتوي المشاركات الفردية على العديد من العناصر المختلفة: - أي عدد من الصفحات، مع بيانات خارج النطاق (out‑of‑band) لكل صفحة تُحدّد نوع المحتوى، واللغة، إلخ. يمكن استخدام أي تنسيق، إذ إن قرار عرض المحتوى بأمان يعود إلى تطبيق العميل - يجب دعم النص العادي، وعلى العملاء القادرين دعم HTML.

  • أي عدد من المرفقات (وأيضًا مع بيانات خارج النطاق تصف المرفق)
  • صورة رمزية صغيرة للمشاركة (ولكن إذا لم تُحدَّد، تُستخدم الصورة الرمزية الافتراضية للمؤلف)
  • مجموعة من المراجع إلى مشاركات أخرى، ومنتديات، وأرشيفات، وURLs، إلخ (قد تشمل المفاتيح اللازمة للنشر، أو الإدارة، أو قراءة المنتديات المشار إليها)

بشكل عام، يعمل Syndie على طبقة المحتوى؛ إذ تُحفظ المشاركات الفردية داخل ملفات ZIP مشفّرة، والمشاركة في المنتدى تعني ببساطة مشاركة هذه الملفات. لا يعتمد الأمر على كيفية نقل الملفات (عبر I2P، Tor، Freenet، gnutella، bittorrent، RSS، usenet، email)، لكن ستُضمَّن أدوات بسيطة للتجميع والتوزيع مع الإصدار القياسي من Syndie.

سيتم التفاعل مع محتوى Syndie بعدة طرق. أولاً، توجد واجهة نصية قابلة للبرمجة، تتيح سطر أوامر أساسيًا ووضعًا تفاعليًا لقراءة المنتديات والكتابة إليها وإدارتها ومزامنتها. على سبيل المثال، فيما يلي نص برمجي بسيط لإنشاء منشور جديد بعنوان “رسالة اليوم” -

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 “MOTD اليوم” set –publicTags motd execute exit

ببساطة مرِّر ذلك عبر الملف التنفيذي syndie وبذلك يتم الأمر: cat motd-script | ./syndie > syndie.log

بالإضافة إلى ذلك، هناك عمل جارٍ على واجهة Syndie رسومية، والتي تتضمن العرض الآمن للنصوص العادية وصفحات HTML (بالطبع، مع دعم التكامل الشفاف مع ميزات Syndie).

ستُمكِّن التطبيقات المبنية على الكود القديم المسمى “sucker” والخاص بـ Syndie من كشط وإعادة كتابة صفحات الويب العادية ومواقع الويب بحيث يمكن استخدامها كمنشورات Syndie أحادية الصفحة أو متعددة الصفحات، بما في ذلك الصور والموارد الأخرى كمرفقات.

لاحقًا، من المخطط أن تتمكّن إضافات firefox/mozilla من اكتشاف واستيراد الملفات المُنسَّقة بتنسيق Syndie ومراجع Syndie، وكذلك إخطار واجهة Syndie الرسومية المحلية بأنه يجب التركيز على عنصر معيّن مثل منتدى أو موضوع أو وسم أو كاتب أو نتيجة بحث.

بالطبع، بما أن Syndie هي، في جوهرها، طبقة محتوى بتنسيق ملف محدد وخوارزميات التشفير، فستظهر على الأرجح تطبيقات أخرى أو تنفيذات بديلة بمرور الوقت.

  • 3.2) Why does Syndie matter?

سمعت خلال الأشهر القليلة الماضية عدداً من الأشخاص يسألون لماذا أعمل على أداة للمنتدى/التدوين - ما علاقة ذلك بتوفير مستوى عالٍ من عدم الكشف عن الهوية؟

الإجابة: كل شيء.

للتلخيص بإيجاز: - يتجنب تصميم Syndie كتطبيق عميل مراعي لإخفاء الهوية بعناية المشكلات المعقّدة لحساسية البيانات التي تقع فيها تقريباً كل التطبيقات التي لم تُبنَ مع أخذ إخفاء الهوية في الحسبان.

  • ومن خلال العمل على طبقة المحتوى، لا يعتمد Syndie على الأداء أو الموثوقية في الشبكات الموزعة مثل I2P أو Tor أو Freenet، وإن كان يمكنه الاستفادة منها حيثما كان ذلك مناسباً.
  • وبفعل ذلك، يمكنه أن يعمل بالكامل عبر آليات صغيرة، ad-hoc (مرتجلة) لتوزيع المحتوى - آليات قد لا تستحق العناء الذي يبذله خصوم أقوياء لمجابهتها (إذ إن ‘العائد’ من كشف بضع عشرات من الأشخاص سيتجاوز على الأرجح كلفة شنّ تلك الهجمات)
  • وهذا يعني أن Syndie سيكون مفيداً حتى دون أن يستخدمه بضعة ملايين من الأشخاص - إذ ينبغي لمجموعات صغيرة غير مترابطة أن تُنشئ مخطط التوزيع الخاص بها لـ Syndie دون الحاجة إلى أي تفاعل مع أو حتى علمٍ من قِبَل أي مجموعات أخرى.
  • ونظراً إلى أن Syndie لا يعتمد على التفاعل الآني، فيمكنه حتى الاستفادة من أنظمة وتقنيات إخفاء هوية عالية الكمون لتجنّب الهجمات التي تكون جميع الأنظمة منخفضة الكمون عرضةً لها (مثل هجمات التقاطع السلبية، وهجمات التوقيت السلبية والفعّالة، وهجمات المزج الفعّالة).

بشكل عام، أرى أن Syndie أكثر أهمية بالنسبة إلى مهمة I2P الأساسية (توفير إخفاء هوية قوي لمن يحتاج إليه) حتى من الـ 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 عبر عدة أبعاد: - واجهة المستخدم: - واجهة مستخدم رسومية (GUI) مبنية على SWT - إضافات متصفح الويب - واجهة نصية لكشط الويب (سحب الصفحات وإعادة كتابتها) - واجهة قراءة IMAP/POP3/NNTP - دعم المحتوى - نص عادي - HTML (عرض آمن داخل واجهة المستخدم الرسومية، وليس في المتصفح) - BBCode (?) - التلقيم - Feedspace، Feedtree، وأدوات مزامنة أخرى منخفضة الكمون - Freenet (تخزين ملفات .snd عند CHK@s والأرشيفات التي تشير إلى ملفات .snd عند SSK@s وUSK@s) - البريد الإلكتروني (إرسال عبر SMTP/mixmaster/mixminion، وقراءة عبر procmail/etc) - Usenet (إرسال عبر NNTP أو remailers، وقراءة عبر (وكيل) NNTP) - بحث نصي كامل مع تكامل Lucene - توسعة HSQLDB من أجل تشفير كامل لقاعدة البيانات - خوارزميات استرشادية إضافية لإدارة الأرشيف

What comes out when depends on when things are done.

    1. Open questions for Syndie

حاليًا، تم تنفيذ Syndie باستخدام بدائيات التشفير القياسية في I2P - SHA256, AES256/CBC, ElGamal2048, DSA. إلا أنّ الأخير بينها هو الاستثناء، لأنه يستخدم مفاتيح عامة بطول 1024 بت ويعتمد على SHA1 (الذي يزداد ضعفًا بسرعة). أحد المقترحات المتداولة في الوسط هو تعزيز DSA باستخدام SHA256، ومع أن ذلك ممكن (وإن لم يُعتمد كمعيار بعد)، فإنه لا يوفّر سوى مفاتيح عامة بطول 1024 بت.

نظرًا إلى أن Syndie لم يُطرح بعد للاستخدام العام، ولا توجد مخاوف بشأن التوافقية العكسية، فلدينا رفاهية تبديل البدائيات التشفيرية. أحد التوجهات هو اختيار توقيعات ElGamal2048 أو RSA2048 بدلًا من DSA، بينما يقترح توجه آخر النظر نحو ECC (تشفير المنحنيات الإهليلجية) (مع توقيعات ECDSA (خوارزمية التوقيع الرقمي بالمنحنى الإهليلجي) وECIES (مخطط التشفير المتكامل بالمنحنى الإهليلجي) للتشفير غير المتماثل)، ربما عند مستويات أمان 256 بت أو 521 بت (بما يوازي أحجام مفاتيح متماثلة 128 بت و256 بت، على التوالي).

أما قضايا براءات الاختراع المتعلقة بـ ECC (التشفير بالمنحنيات الإهليلجية)، فيبدو أنها ذات صلة فقط بتحسينات محددة (ضغط النقاط) وخوارزميات لا نحتاجها (EC MQV). لا يوجد الكثير من حيث دعم Java، رغم أن مكتبة Bouncy Castle يبدو أن لديها بعض الشيفرة. ومع ذلك، من المرجح ألا يكون من الصعب إضافة أغلفة صغيرة (wrappers) لـ libtomcrypt أو openssl أو crypto++ أيضًا، كما فعلنا مع libGMP (مما منحنا jbigi).

هل لديك أي أفكار حول ذلك؟

    1. ???

هناك الكثير مما ينبغي استيعابه أعلاه، ولهذا السبب (باقتراح من cervantes) أرسل ملاحظات الحالة هذه مبكرًا جدًا. إذا كانت لديك أي تعليقات أو أسئلة أو مخاوف أو اقتراحات، فيُرجى الانضمام إلى #i2p الليلة عند الساعة 8 مساءً بتوقيت UTC على irc.freenode.net/irc.postman.i2p/irc.freshcoffee.i2p لاجتماعنا سعال الأسبوعي!

=jr