Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
/ar/proposals/Recent content in اقتراحات I2P on I2P - مشروع الإنترنت غير المرئيHugoar-SA/ar/proposals/114-encrypted-streaming-flag/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/114-encrypted-streaming-flag/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذه الاقتراح يتعلق بإضافة علامة إلى بروتوكول التدفق تحدد نوع التشفير المستخدم من طرف إلى طرف.</p> <h2 id="الدافع">الدافع</h2> <p>يمكن أن تواجه التطبيقات المثقلة للغاية نقصًا في علامات ElGamal/AES+SessionTags.</p> <h2 id="التصميم">التصميم</h2> <p>إضافة علامة جديدة في مكان ما ضمن بروتوكول التدفق. إذا جاء حزمة مع هذه العلامة فهذا يعني أن الحمولة مشفرة بتقنية AES باستخدام المفتاح الخاص ومفتاح عام للند. وسيسمح ذلك بالقضاء على التشفير بالجاردليك (ElGamal/AES) ومشكلة نقص العلامات.</p> <p>قد يتم تعيينها لكل حزمة أو لكل تيار من خلال SYN.</p>/ar/proposals/149-b32-encrypted-ls2/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/149-b32-encrypted-ls2/<h2 id="ملاحظة">ملاحظة</h2> <p>نشر الشبكة والاختبارات قيد التقدم. عرضة للتعديلات الطفيفة. انظر <a href="../../ar/docs/specs/b32-for-encrypted-leasesets/">SPEC</a> للمواصفات الرسمية.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>عناوين Base 32 القياسية (&ldquo;b32&rdquo;) تحتوي على تجزئة الوجهة. هذا لن يعمل مع LS2 المشفر (اقتراح 123).</p> <p>لا يمكنك استخدام عنوان base 32 تقليدي لـ LS2 المشفر (اقتراح 123)، لأنه يحتوي فقط على تجزئة الوجهة. لا يوفّر المفتاح العام غير المحجب. يجب على العملاء معرفة المفتاح العام للوجهة، نوع التوقيع، نوع التوقيع المحجب، ومفتاح سري أو خاص اختياري لإحضار وفك تشفير مجموعة الإيجار. لذلك، فإن عنوان base 32 وحده غير كافٍ. يحتاج العميل إما الوجهة الكاملة (التي تحتوي على المفتاح العام)، أو المفتاح العام بمفرده. إذا كان لدى العميل الوجهة الكاملة في دفتر العناوين، وكان دفتر العناوين يدعم البحث العكسي بواسطة التجزئة، يمكن حينها استرداد المفتاح العام.</p>/ar/proposals/107-bep9-information-recovery/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/107-bep9-information-recovery/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح يتعلق بإضافة استعادة كاملة للمعلومات إلى تنفيذ I2P لـ BEP9.</p> <h2 id="الدافع">الدافع</h2> <p>لا يقوم BEP9 بإرسال ملف التورنت بالكامل، وبالتالي يفقد العديد من عناصر القاموس الهامة، ويغير المجموع الكلي SHA1 لملفات التورنت. هذا سيء للروابط المغناطيسية، وسيء لأن المعلومات الهامة تضيع. قوائم المتتبعات، التعليقات، وأي بيانات إضافية تكون مفقودة. من المهم وجود طريقة لاستعادة هذه المعلومات، ويجب أن تضيف شيئا قليلا قدر الإمكان إلى ملف التورنت. كما يجب ألا تكون دائرية التبعية. لا ينبغي أن تؤثر معلومات الاسترداد على العملاء الحاليين بأي شكل من الأشكال. ملفات التورنت التي لا تحتوي على متتبع (عنوان URL للمراقبة هو حرفيا &rsquo;trackerless&rsquo;) لا تحتوي على الحقل الإضافي، حيث أنها مخصصة لاستخدام بروتوكول المغناطيس في الاكتشاف والتنزيل، والذي لا يفقد المعلومات من الأصل.</p>/ar/proposals/145-ecies/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/145-ecies/<h2 id="الدافع">الدافع</h2> <p>ECIES-P256 أسرع بكثير من ElGamal. هناك عدد قليل من مواقع i2pd التي تستخدم نوع التشفير ECIES-P256 بالفعل ويجب أن يكون Java قادرًا على التواصل معها وبالعكس. يدعمه i2pd منذ الإصدار 2.16.0 (0.9.32 Java).</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>تقدم هذه الاقتراح نوع تشفير جديد ECIES-P256 يمكن أن يظهر في جزء الشهادة من الهوية، أو كنمط مفتاح تشفير منفصل في LeaseSet2. يمكن استخدامه في RouterInfo، LeaseSet1 و LeaseSet2.</p> <h3 id="مواقع-مفاتيح-elgamal">مواقع مفاتيح ElGamal</h3> <p>كمراجعة، يمكن العثور على مفاتيح ElGamal العامة بحجم 256 بايت في هياكل البيانات التالية. الرجوع إلى مواصفات الهياكل المشتركة.</p>/ar/proposals/144-ecies-x25519-aead-ratchet/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/144-ecies-x25519-aead-ratchet/<h2 id="ملاحظة">ملاحظة</h2> <p>النشر والاختبار على الشبكة قيد التقدم. خاضع لمراجعات طفيفة. انظر <a href="../../ar/docs/specs/ecies/">SPEC</a> للمواصفات الرسمية.</p> <p>السمات التالية لم تُنفَّذ اعتبارًا من الإصدار 0.9.46:</p> <ul> <li>كتل MessageNumbers وOptions وTermination</li> <li>استجابات طبقة البروتوكول</li> <li>مفتاح ثابت صفري</li> <li>البث المتعدد (Multicast)</li> </ul> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا اقتراح لنوع تشفير جديد من طرف إلى طرف منذ بداية I2P، ليحل محل ElGamal/AES+SessionTags <a href="../../ar/docs/specs/elgamal-aes/">Elg-AES</a> .</p> <p>يعتمد على أعمال سابقة كالتالي:</p> <ul> <li>مواصفات الهياكل المشتركة <a href="../../ar/docs/specs/common-structures/">Common Structures</a> </li> <li>مواصفات <a href="../../ar/docs/specs/i2np/">I2NP</a> متضمنة LS2</li> <li>ElGamal/AES+Session Tags <a href="../../ar/docs/specs/elgamal-aes/">Elg-AES</a> </li> <li><a href="http://zzz.i2p/topics/1768">http://zzz.i2p/topics/1768</a> نظرة عامة على التشفير غير المتماثل الجديد</li> <li>نظرة عامة على التشفير منخفض المستوى <a href="../../ar/docs/specs/cryptography/">CRYPTO-ELG</a> </li> <li>ECIES <a href="http://zzz.i2p/topics/2418">http://zzz.i2p/topics/2418</a> </li> <li><a href="../../ar/docs/specs/ntcp2/">NTCP2</a> <a href="../../ar/proposals/111-ntcp-2/">اقتراح 111</a> </li> <li>123 إدخالات جديدة في netDB</li> <li>142 قالب تشفير جديد</li> <li>بروتوكول <a href="https://noiseprotocol.org/noise.html">Noise</a> </li> <li>خوارزمية الترس المزدوج <a href="https://signal.org/docs/">Signal</a> (double ratchet)</li> </ul> <p>الهدف هو دعم التشفير الجديد للتواصل من طرف إلى طرف، من وجهة إلى وجهة.</p>/ar/proposals/118-i2pcontrol-api-2/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/118-i2pcontrol-api-2/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تقدم هذه الاقتراح API2 لـ I2PControl.</p> <p>تم رفض هذا الاقتراح ولن يتم تنفيذه لأنه يكسر التوافق مع الإصدارات السابقة. انظر رابط موضوع النقاش للحصول على التفاصيل.</p> <h3 id="تنبيه-للمطورين">تنبيه للمطورين!</h3> <p>جميع معلمات RPC ستصبح الآن أحرف صغيرة. هذا <em>سيكسر</em> التوافق مع تنفيذات API1. السبب في ذلك هو توفير للمستخدمين من API2 فأعلى بأبسط وأكثر واجهة برمجة تطبيقات تماسكًا ممكنة.</p> <h2 id="مواصفات-api-2">مواصفات API 2</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-json" data-lang="json"><span style="display:flex;"><span>{ </span></span><span style="display:flex;"><span> <span style="color:#f92672">&#34;id&#34;</span>: <span style="color:#e6db74">&#34;id&#34;</span>, </span></span><span style="display:flex;"><span> <span style="color:#f92672">&#34;method&#34;</span>: <span style="color:#e6db74">&#34;method_name&#34;</span>, </span></span><span style="display:flex;"><span> <span style="color:#f92672">&#34;params&#34;</span>: { </span></span><span style="display:flex;"><span> <span style="color:#f92672">&#34;token&#34;</span>: <span style="color:#e6db74">&#34;auth_token&#34;</span>, </span></span><span style="display:flex;"><span> <span style="color:#f92672">&#34;method_param&#34;</span>: <span style="color:#e6db74">&#34;method_parameter_value&#34;</span>, </span></span><span style="display:flex;"><span> }, </span></span><span style="display:flex;"><span> <span style="color:#f92672">&#34;jsonrpc&#34;</span>: <span style="color:#e6db74">&#34;2.0&#34;</span> </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> { </span></span><span style="display:flex;"><span> <span style="color:#f92672">&#34;id&#34;</span>: <span style="color:#e6db74">&#34;id&#34;</span>, </span></span><span style="display:flex;"><span> <span style="color:#f92672">&#34;result&#34;</span>: <span style="color:#e6db74">&#34;result_value&#34;</span>, </span></span><span style="display:flex;"><span> <span style="color:#f92672">&#34;jsonrpc&#34;</span>: <span style="color:#e6db74">&#34;2.0&#34;</span> </span></span><span style="display:flex;"><span> } </span></span></code></pre></div><h3 id="المعلمات">المعلمات</h3> <p><strong><code>&quot;id&quot;</code></strong></p>/ar/proposals/110-leaseset-2/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/110-leaseset-2/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح يتعلق بتنسيق LeaseSet جديد يدعم أنواع التشفير الحديثة.</p> <h2 id="الدافع">الدافع</h2> <p>التشفير من النهاية إلى النهاية المستخدم عبر أنفاق I2P يمتلك مفاتيح تشفير وتوقيع منفصلة. توجد مفاتيح التوقيع في وِجهة النفق، التي تم تمديدها بالفعل بشهادات المفاتيح لدعم أنواع توقيع حديثة. ومع ذلك، فإن مفاتيح التشفير جزء من LeaseSet، الذي لا يحتوي على أي شهادات. لذلك، من الضروري تنفيذ تنسيق LeaseSet جديد، وإضافة الدعم لتخزينه في قاعدة بيانات الشبكة (netDb).</p>/ar/proposals/155-streaming-mtu-ecies/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/155-streaming-mtu-ecies/<h2 id="ملاحظة">ملاحظة</h2> <p>نشر الشبكة واختبارها قيد التقدم. خاضع لتعديلات طفيفة.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <h3 id="ملخص">ملخص</h3> <p>تقلل ECIES تكلفة الرسائل في الجلسة الحالية (ES) بحوالي 90 بايت. وبالتالي يمكننا زيادة MTU بحوالي 90 بايت للاتصالات التي تستخدم ECIES. انظر <a href="../../ar/docs/specs/ecies/#overhead">مواصفات ECIES</a> ، و<a href="../../ar/docs/specs/streaming/#flags-and-option-data-fields">مواصفات البث</a> ، و<a href="../../ar/docs/api/streaming/">توثيق واجهة برمجة تطبيقات البث</a> .</p> <p>بدون زيادة MTU، في كثير من الحالات لن تكون وفورات التكلفة &ldquo;موفرة فعليًا&rdquo;، لأن الرسائل ستُملأ لتستخدم رسالتي نفق كاملتين على أي حال.</p> <p>هذا الاقتراح لا يتطلب أي تغيير في المواصفات. تم نشره كاقتراح فقط لتيسير المناقشة وبناء توافق في الآراء حول القيمة الموصى بها وتفاصيل التنفيذ.</p>/ar/proposals/108-multipath-tcp-for-streaming/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/108-multipath-tcp-for-streaming/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذه الاقتراح يدور حول تمديد البث لاستخدام أنفاق متعددة لكل اتصال، مشابه لـ TCP متعدد المسار.</p> <h2 id="الدافع">الدافع</h2> <p>تستخدم أنفاق العملاء بواسطة مكتبة البث بطريقة TCP قياسية إلى حد ما.</p> <p>من الأفضل السماح بحل مشابه لـ TCP متعدد المسار، حيث يتم استخدام أنفاق العملاء بناءً على خصائص فردية مثل:</p> <ul> <li>زمن الانتقال</li> <li>السعة</li> <li>التوفر</li> </ul> <h2 id="التصميم">التصميم</h2> <p>لاحقاً لتحديده</p>/ar/proposals/111-ntcp-2/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/111-ntcp-2/<h2 id="ملاحظة">ملاحظة</h2> <p>مرحلة الاقتراح مغلقة. انظر <a href="../../ar/docs/specs/ntcp2/">المواصفات</a> لمواصفات رسمیة. يمكن الإشارة إلى هذا الاقتراح لمعلومات الخلفية.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>يصف هذا الاقتراح بروتوكول اتفاق مصادق على المفتاح لتحسين مقاومة <a href="../../ar/docs/ntcp/">NTCP</a> للعديد من أشكال التعريف الآلي والهجمات.</p> <p>يتم تنظيم الاقتراح على النحو التالي: يتم تقديم الأهداف الأمنية، يليها مناقشة البروتوكول الأساسي. بعد ذلك، يتم تقديم مواصفات كاملة لجميع رسائل البروتوكول. أخيرًا، يتم مناقشة عناوين الموجهات وتحديد الإصدار. كما يتم تضمين ملحق يناقش هجومًا عامًا على مخططات التعبئة الشائعة، بالإضافة إلى ملحق يحتوي على عدد من المرشحين للمصادق على الشفرة.</p>/ar/proposals/109-pt-transport/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/109-pt-transport/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح يهدف إلى إنشاء وسيلة نقل I2P تتصل بموجهات أخرى من خلال وسائل النقل الإضافية.</p> <h2 id="الدافع">الدافع</h2> <p>تم تطوير وسائل النقل الإضافية (PTs) بواسطة Tor كوسيلة لإضافة وسائل نقل التشويش إلى جسور Tor بطريقة نموذجية.</p> <p>لدى I2P بالفعل نظام نقل نمطي يقلل من العوائق لإضافة وسائل نقل بديلة. إضافة دعم لـ PTs سيتيح لـ I2P طريقة سهلة لتجربة بروتوكولات بديلة، والاستعداد لمقاومة الحظر.</p> <h2 id="التصميم">التصميم</h2> <p>هناك عدة طبقات محتملة للتنفيذ:</p>/ar/proposals/148-eddsa-blake2b-ed25519/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/148-eddsa-blake2b-ed25519/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح يضيف نوع توقيع جديد باستخدام BLAKE2b-512 مع سلاسل التخصيص والأملاح، لاستبدال SHA-512. هذا سيقضي على ثلاث فئات من الهجمات المحتملة.</p> <h2 id="الدافع">الدافع</h2> <p>أثناء المناقشات والتصميم الخاص بـ NTCP2 (الاقتراح 111) و LS2 (الاقتراح 123)، نظرنا بإيجاز في هجمات مختلفة كانت ممكنة، وكيفية منعها. ثلاث من هذه الهجمات هي هجمات تمديد الطول، والهجمات عبر البروتوكولات، وتحديد الرسائل المكررة.</p> <p>بالنسبة لكل من NTCP2 و LS2، قررنا أن هذه الهجمات لم تكن ذات صلة مباشرة بالمقترحات المطروحة، وأن أي حلول تتعارض مع هدف تقليل البدائيات الجديدة إلى أدنى حد. كما حددنا أن سرعة دوال التشفير (hash functions) في هذه البروتوكولات لم تكن عاملاً مهماً في قراراتنا. لذلك، أجلنا في الغالب الحل إلى مقترح منفصل. وبينما أضفنا بعض ميزات التخصيص إلى مواصفات LS2، لم نطلب أي دوال تشفير جديدة.</p>/ar/proposals/161-ri-dest-padding/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/161-ri-dest-padding/<h2 id="الحالة">الحالة</h2> <p>تم التنفيذ في الإصدار 0.9.57. نترك هذا الاقتراح مفتوحًا حتى نتمكن من تحسين الأفكار والنقاش حولها في قسم &ldquo;التخطيط المستقبلي&rdquo;.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <h3 id="الملخص">الملخص</h3> <p>لم يتم استخدام المفتاح العمومي ElGamal في الـ Destinations منذ الإصدار 0.6 (2005). بينما تنص مواصفاتنا على أن هذا الحقل غير مستخدم، فإنها لا تقول إن التنفيذ يمكنه تجنب توليد زوج مفاتيح ElGamal وببساطة ملء الحقل ببيانات عشوائية.</p> <p>نقترح تغيير المواصفات لتشير إلى أن الحقل يتم تجاهله، وأنه يجوز للتنفيذات ملء الحقل ببيانات عشوائية. هذا التغيير متوافق مع الإصدارات السابقة. لا يوجد تنفيذ معروف يتحقق من صحة المفتاح العمومي ElGamal.</p>/ar/proposals/159-ssu2/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/159-ssu2/<h2 id="status">Status</h2> <p>Rollout plan:</p> <table> <thead> <tr> <th>Feature</th> <th>Testing (not default)</th> <th>Enabled by default</th> </tr> </thead> <tbody> <tr> <td>Local test code</td> <td>2022-02</td> <td></td> </tr> <tr> <td>Joint test code</td> <td>2022-03</td> <td></td> </tr> <tr> <td>Joint test in-net</td> <td>0.9.54 2022-05</td> <td></td> </tr> <tr> <td>Freeze basic protocol</td> <td>0.9.54 2022-05</td> <td></td> </tr> <tr> <td>Basic Session</td> <td>0.9.55 2022-08</td> <td>0.9.56 2022-11</td> </tr> <tr> <td>Address Validation (Retry)</td> <td>0.9.55 2022-08</td> <td>0.9.56 2022-11</td> </tr> <tr> <td>Fragmented RI in handshake</td> <td>0.9.55 2022-08</td> <td>0.9.56 2022-11</td> </tr> <tr> <td>New Token</td> <td>0.9.55 2022-08</td> <td>0.9.57 2022-11</td> </tr> <tr> <td>Freeze extended protocol</td> <td>0.9.55 2022-08</td> <td></td> </tr> <tr> <td>Relay</td> <td>0.9.55 2022-08</td> <td>0.9.56 2022-11</td> </tr> <tr> <td>Peer Test</td> <td>0.9.55 2022-08</td> <td>0.9.56 2022-11</td> </tr> <tr> <td>Enable for random 2%</td> <td>0.9.55 2022-08</td> <td></td> </tr> <tr> <td>Path Validation</td> <td>0.9.55+ dev</td> <td>0.9.56 2022-11</td> </tr> <tr> <td>Connection Migration</td> <td>0.9.55+ dev</td> <td>0.9.56 2022-11</td> </tr> <tr> <td>Immediate ACK flag</td> <td>0.9.55+ dev</td> <td>0.9.56 2022-11</td> </tr> <tr> <td>Key Rotation</td> <td>0.9.57 2023-02</td> <td>0.9.58 2023-05</td> </tr> <tr> <td>Disable SSU 1 (i2pd)</td> <td>0.9.56 2022-11</td> <td></td> </tr> <tr> <td>Disable SSU 1 (Java I2P)</td> <td>0.9.58 2023-05</td> <td>0.9.61 2023-12</td> </tr> <tr> <td>Basic Session includes the handshake and data phase. Extended protocol includes relay and peer test.</td> <td></td> <td></td> </tr> </tbody> </table> <h2 id="overview">Overview</h2> <p>This proposal describes an authenticated key agreement protocol to improve the resistance of <a href="../../ar/docs/specs/ssu2/">SSU</a> to various forms of automated identification and attacks.</p>/ar/proposals/152-ecies-tunnels/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/152-ecies-tunnels/<h2 id="ملاحظة">ملاحظة</h2> <p>نشر الشبكة والاختبار قيد التقدم. قابل للمراجعات الطفيفة. راجع <a href="../../ar/docs/specs/tunnel-implementation/">SPEC</a> للمواصفات الرسمية.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>تقترح هذه الوثيقة تغييرات على تشفير رسائل Tunnel Build باستخدام العناصر التشفيرية الأساسية المقدمة بواسطة <a href="../../ar/docs/specs/ecies/">ECIES-X25519</a> . إنها جزء من الاقتراح الشامل <a href="../../ar/proposals/156-ecies-routers">Proposal 156</a> لتحويل أجهزة router من مفاتيح ElGamal إلى مفاتيح ECIES-X25519.</p> <p>لأغراض نقل الشبكة من ElGamal + AES256 إلى ECIES + ChaCha20، تُعتبر الأنفاق التي تحتوي على مزيج من موجهات ElGamal و ECIES ضرورية. يتم توفير مواصفات للتعامل مع القفزات المختلطة للأنفاق. لن يتم إجراء أي تغييرات على تنسيق أو معالجة أو تشفير قفزات ElGamal.</p>/ar/proposals/119-bidirectional-tunnels/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/119-bidirectional-tunnels/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذه الاقتراح يتعلق بتنفيذ أنفاق ثنائية الاتجاه في I2P.</p> <h2 id="الدافع">الدافع</h2> <p>i2pd سوف تقدم أنفاق ثنائية الاتجاه من خلال مسيرات i2pd الأخرى فقط في الوقت الراهن. بالنسبة للشبكة، ستظهر كأنفاق واردة وصادرة عادية.</p> <h2 id="التصميم">التصميم</h2> <h3 id="أهداف">أهداف</h3> <ol> <li>تقليل استخدام الشبكة ووحدة المعالجة المركزية عن طريق تقليل عدد رسائل بناء النفق</li> <li>القدرة على معرفة فورًا إذا كان المشارك قد انقطع</li> <li>إنشاء ملفات تعريف وإحصاءات أكثر دقة</li> <li>استخدام شبكات مظلمة أخرى كوسطاء</li> </ol> <h3 id="تعديلات-النفق">تعديلات النفق</h3> <p>بناء النفق</p>/ar/proposals/139-i2p-mime-types/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/139-i2p-mime-types/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تحديد أنواع MIME لأشكال ملفات I2P الشائعة. قم بتضمين التعريفات في حزم Debian. توفير معالج لنوع .su3، وربما الأنواع الأخرى.</p> <h2 id="الدافع">الدافع</h2> <p>لتسهيل عملية إعادة التوزيع وتثبيت الملحقات عند التحميل باستخدام المتصفح، نحتاج إلى نوع MIME ومعالج لملفات .su3.</p> <p>بينما نحن في ذلك، بعد تعلم كيفية كتابة ملف تعريف MIME، وفقًا لمعيار freedesktop.org، يمكننا إضافة تعريفات لأنواع ملفات I2P الشائعة الأخرى. على الرغم من أنها أقل فائدة للملفات التي لا يتم تحميلها عادةً، مثل قاعدة البيانات لحظر دفتر العناوين (hostsdb.blockfile)، فإن هذه التعريفات ستسمح بتحديد أيقونات الملفات بشكل أفضل عند استخدام عارض دليل رسومي مثل &ldquo;nautilus&rdquo; على Ubuntu.</p>/ar/proposals/112-addressbook-subscription-feed-commands/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/112-addressbook-subscription-feed-commands/<h2 id="ملاحظة">ملاحظة</h2> <p>اكتمل نشر الشبكة. انظر <a href="../../ar/docs/specs/subscription/">SPEC</a> للمواصفات الرسمية.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح يتعلق بتمديد تغذية الاشتراك في العناوين مع الأوامر، لتمكين خوادم الأسماء من بث تحديثات الإدخال من حاملي أسماء النطاقات. تم تنفيذه في الإصدار 0.9.26.</p> <h2 id="الدافع">الدافع</h2> <p>حاليًا، تقوم خوادم اشتراك hosts.txt بإرسال البيانات في صيغة hosts.txt، وهي كالتالي:</p> <pre><code>```text example.i2p=b64destination ``` </code></pre> <p>هناك عدة مشاكل مع هذا:</p> <ul> <li>لا يمكن لحاملي أسماء النطاقات تحديث الوجهة المرتبطة بأسمائهم (لترقية مفتاح التوقيع إلى نوع أقوى مثلاً).</li> <li>لا يمكن لحاملي أسماء النطاقات التنازل عن أسمائهم عشوائيًا؛ يجب عليهم تقديم مفاتيح الوجهة الخاصة مباشرة إلى الحامل الجديد.</li> <li>لا توجد طريقة للمصادقة على أن النطاق الفرعي يتم التحكم به من قبل اسم النطاق الأساسي المقابل؛ حاليًا يتم فرض ذلك بشكل فردي من قبل بعض خوادم الأسماء.</li> </ul> <h2 id="التصميم">التصميم</h2> <p>يضيف هذا الاقتراح عددًا من سطور الأوامر إلى صيغة hosts.txt. مع هذه الأوامر، يمكن لخوادم الأسماء توسيع خدماتها لتوفير عدد من الميزات الإضافية. سيتمكن العملاء الذين ينفذون هذا الاقتراح من الاستماع لهذه الميزات عبر عملية الاشتراك المنتظمة.</p>/ar/proposals/106-ntcp-obfuscation/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/106-ntcp-obfuscation/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تتعلق هذه الاقتراح بإعادة تصميم نقل NTCP لتحسين مقاومته للتعرف التلقائي.</p> <h2 id="الدوافع">الدوافع</h2> <p>يتم تشفير بيانات NTCP بعد الرسالة الأولى (وتظهر الرسالة الأولى كبيانات عشوائية)، مما يمنع تحديد البروتوكول من خلال &ldquo;تحليل الحمولة&rdquo;. لا يزال عرضة لتحديد البروتوكول من خلال &ldquo;تحليل التدفق&rdquo;. وذلك لأن الرسائل الأربع الأولى (أي المصافحة) لها طول ثابت (288 و304 و448 و48 بايت).</p> <p>من خلال إضافة كميات عشوائية من البيانات العشوائية لكل من الرسائل، يمكننا جعل الأمر أصعب بكثير.</p>/ar/proposals/123-new-netdb-entries/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/123-new-netdb-entries/<h2 id="الحالة">الحالة</h2> <p>تم الانتهاء من أجزاء من هذا الاقتراح، وتم تنفيذه في الإصدار 0.9.38 و0.9.39.<br> تم الآن تحديث المواصفات الخاصة بالهياكل المشتركة، وI2CP، وI2NP، وغيرها لتعكس التغييرات المدعومة حاليًا.</p> <p>الأجزاء المكتملة لا تزال عرضة لمراجعات طفيفة.<br> أما الأجزاء الأخرى من هذا الاقتراح فهي لا تزال قيد التطوير وعرضة لمراجعات جوهرية.</p> <p>تُعد ميزة البحث عن الخدمة (الأنواع 9 و11) ذات أولوية منخفضة وغير مجدولة، وقد يتم فصلها إلى اقتراح منفصل.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا تحديث وتجميع للإقتراحات الأربعة التالية:</p>/ar/proposals/124-session-tags-reset-message/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/124-session-tags-reset-message/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح هو لرسالة I2NP يمكن استخدامها لإعادة تعيين علامات الجلسة بين جهتين.</p> <h2 id="الدافع">الدافع</h2> <p>تخيل أن هناك جهة لديها مجموعة من العلامات المؤكدة إلى جهة أخرى. لكن تلك الجهة أعيد تشغيلها أو فقدت هذه العلامات بطريقة ما. الجهة الأولى تستمر في إرسال الرسائل مع العلامات والجهة الثانية لا تستطيع فك التشفير. يجب أن تكون الجهة الثانية قادرة على إخبار الجهة الأولى بإعادة التعيين (البدء من الصفر) من خلال إضافة فصوص ثوم إضافية بنفس الطريقة التي ترسل بها LeaseSet محدثة.</p>/ar/proposals/141-deprecate-hostnames-in-addresses/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/141-deprecate-hostnames-in-addresses/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>اعتبارًا من الإصدار 0.9.32، تحديث مواصفات netdb لإيقاف استخدام أسماء النطاقات في معلومات الموجهات، أو بشكل أدق، في العناوين الفردية للموجه. في جميع تطبيقات I2P، الموجهات الناشرة التي تم تكوينها بأسماء النطاقات يجب أن تستبدلها بعناوين IP قبل النشر، ويجب أن تتجاهل الموجهات الأخرى العناوين التي تحتوي على أسماء نطاقات. ينبغي ألا تقوم الموجهات بعمليات بحث DNS لأسماء النطاقات المنشورة.</p> <h2 id="الدافع">الدافع</h2> <p>تم السماح باستخدام أسماء النطاقات في عناوين الموجهات منذ بداية I2P. ومع ذلك، تقوم عدد قليل جدًا من الموجهات بنشر أسماء النطاقات، لأنه يتطلب وجود اسم نطاق عام (وهو ما يمتلكه قليل من المستخدمين)، وتكوين يدوي (وهو ما يقوم به قليل من المستخدمين). في عينة حديثة، كانت 0.7% من الموجهات تنشر اسم نطاق.</p>/ar/proposals/126-ipv6-peer-testing/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/126-ipv6-peer-testing/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تهدف هذه المقترح إلى تنفيذ اختبار الأقران SSU لـ IPv6. تم تنفيذه في 0.9.27.</p> <h2 id="الدافع">الدافع</h2> <p>لا يمكننا تحديد وتتبع بشكل موثوق إذا كان عنوان IPv6 الخاص بنا مغلقًا بجدار ناري.</p> <p>عندما أضفنا دعم IPv6 منذ سنوات، افترضنا أن IPv6 لم يكن مغلقًا بجدار ناري.</p> <p>مؤخرًا، في الإصدار 0.9.20 (مايو 2015)، قمنا بتقسيم حالة الاتصال v4/v6 داخليًا (التذكرة #1458). راجع تلك التذكرة للحصول على معلومات شاملة وروابط.</p> <p>إذا كان لديك كلتا v4 وv6 مغلقتين بجدار ناري، يمكنك فقط إجبار الإغلاق في قسم تكوين TCP على /confignet.</p>/ar/proposals/113-leaseset-key-persistence/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/113-leaseset-key-persistence/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح يتعلق باستمرارية البيانات الإضافية في LeaseSet التي هي حاليًا مؤقتة. تم التنفيذ في 0.9.18.</p> <h2 id="الدافع">الدافع</h2> <p>في 0.9.17 تمت إضافة استمرارية لمفتاح تقطيع netDb، المخزن في i2ptunnel.config. يساعد ذلك في منع بعض الهجمات من خلال الحفاظ على نفس القطعة بعد إعادة التشغيل، كما يمنع إمكانية التتبع مع إعادة تشغيل الموجه.</p> <p>هناك شيئين آخرين هما أسهل في التتبع مع إعادة تشغيل الموجه: مفاتيح تشفير وتوقيع leaseset. هذه المفاتيح حاليًا ليست مستمرة.</p>/ar/proposals/166-identity-aware-proxies/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/166-identity-aware-proxies/<h3 id="اقتراح-لنوع-جديد-من-أنفاق-الوكيل-http-يراعي-المضيف">اقتراح لنوع جديد من أنفاق الوكيل HTTP يراعي المضيف</h3> <p>هذا اقتراح لحل &ldquo;مشكلة الهوية المشتركة&rdquo; في الاستخدام التقليدي لبروتوكول HTTP عبر I2P، من خلال إدخال نوع جديد من أنفاق وكيل HTTP. يتمتع هذا النوع من الأنفاق بسلوك إضافي يهدف إلى منع أو تقليل فائدة التتبع الذي قد تقوم به مشغلو خدمات مخفية عدائية، ضد وكلاء المستخدم (المتصفحات) وتطبيق عميل I2P نفسه.</p> <h4 id="ما-هي-مشكلة-الهوية-المشتركة">ما هي &ldquo;مشكلة الهوية المشتركة&rdquo;؟</h4> <p>تحدث &ldquo;مشكلة الهوية المشتركة&rdquo; عندما يشترك وكيل مستخدم على شبكة تراكب ذات عنونة تشفيرية في هوية تشفيرية مع وكيل مستخدم آخر. يحدث هذا، على سبيل المثال، عندما يتم تهيئة كل من متصفح Firefox وأداة GNU Wget لاستخدام نفس وكيل HTTP.</p>/ar/proposals/165-ssu2-fix/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/165-ssu2-fix/<p>اقتراح مقدم من weko، أوignal، the Anonymous و zzz.</p> <h3 id="نظرة-عامة">نظرة عامة</h3> <p>تقترح هذه الوثيقة تغييرات على SSU2 بعد هجوم على I2P استغل الثغرات في SSU2. الهدف الأساسي هو تعزيز الأمان ومنع هجمات الحرمان من الخدمة الموزعة (DDoS) ومحاولات إزالة إخفاء الهوية.</p> <h3 id="نموذج-التهديد">نموذج التهديد</h3> <p>يقوم مهاجم بإنشاء RIs وهمية جديدة (الموجه غير موجود): هو RI عادي، ولكنه يضع العنوان، المنفذ، ومفاتيح s و i من موجه Bob الحقيقي، ثم يغمر الشبكة. عندما نحاول الاتصال بهذا الموجه (كما نظن الحقيقي)، يمكننا كـ Alice الاتصال بهذا العنوان، ولكن لا يمكننا التأكد مما إذا كان تم ذلك باستخدام RI الحقيقي لـ Bob. هذا ممكن واستخدم لهجوم الحرمان من الخدمة الموزعة (صنع كمية كبيرة من مثل هذه الـ RIs وإغراق الشبكة)، كما يمكن أن يجعل هجمات إزالة إخفاء الهوية أسهل من خلال الإطاحة بأجهزة التوجيه الجيدة وعدم الإطاحة بأجهزة التوجيه الخاصة بالمهاجم، إذا قمنا بحظر IP مع العديد من RIs (بدلاً من توزيع أفضل لبناء النفق إلى هذه RIs باعتبارها موجه واحد).</p>/ar/proposals/101-multicast/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/101-multicast/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>الفكرة الأساسية: إرسال نسخة واحدة عبر النفق الخاص بك للخارج، يقوم نقطة النهاية الخارجة بالتوزيع على جميع بوابات الدخول. التشفير من النهاية للنهاية مستبعد.</p> <h2 id="التصميم">التصميم</h2> <ul> <li>نوع رسالة نفق البث المتعدد الجديد (نوع الإرسال = 0x03)</li> <li>توزيع نقطة النهاية الخارجة للبث المتعدد</li> <li>نوع رسالة I2NP Multicast جديد؟</li> <li>نوع رسالة I2CP Multicast SendMessageMessage جديد</li> <li>عدم تشفير الموجه-الموجه في OutNetMessageOneShotJob (الثوم؟)</li> </ul> <p>تطبيق:</p> <ul> <li>وكيل RTSP؟</li> </ul> <p>Streamr:</p> <ul> <li>ضبط MTU؟ أو القيام بذلك في التطبيق؟</li> <li>الاستقبال والإرسال عند الطلب</li> </ul>/ar/proposals/122-service-lookup/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/122-service-lookup/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا هو الاقتراح الكامل لكل شيء في قاعدة بيانات الشبكة. ويعرف أيضًا باسم الإرسال لأي وجهة. سيكون هذا هو الاقتراح الرابع لنوع LS2.</p> <h2 id="الدافع">الدافع</h2> <p>أفترض أنك أردت الإعلان عن وجهتك كنقطة خروج، أو كعقدة GNS، أو كبوابة Tor، أو كدليل Bittorrent DHT أو imule أو i2phex أو Seedless للتمهيد، إلخ. يمكنك تخزين هذه المعلومات في قاعدة بيانات الشبكة بدلاً من استخدام طبقة تمهيد أو معلومات منفصلة.</p> <p>لا يوجد شخص مسؤول، لذا على عكس التعدد الهائل للخدمات، لا يمكنك الحصول على قائمة مفوضة موقعة. لذا ستقوم فقط بنشر سجلك إلى floodfill. سوف يقوم الـfloodfill بتجميع هذه البيانات وإرسالها كاستجابة للاستعلامات.</p>/ar/proposals/147-transport-network-id-check/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/147-transport-network-id-check/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>لا يرفض NTCP2 (الاقتراح 111) اتصالات من معرفات شبكة مختلفة في مرحلة طلب الجلسة. يجب أن يتم رفض المرور حاليًا في مرحلة تأكيد الجلسة عندما يتحقق بوب من RI لأليس.</p> <p>وبالمثل، لا يرفض SSU اتصالات من معرفات شبكة مختلفة في مرحلة طلب الجلسة. يجب أن يتم رفض المرور حاليًا بعد مرحلة تأكيد الجلسة عندما يتحقق بوب من RI لأليس.</p> <p>يقوم هذا الاقتراح بتغيير مرحلة طلب الجلسة لكلا النقلين لتضمين معرف الشبكة بطريقة متوافقة مع الإصدارات السابقة.</p>/ar/proposals/140-invisible-multihoming/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/140-invisible-multihoming/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>يحدد هذا الاقتراح تصميم بروتوكول يمكّن عميل I2P أو خدمة أو عملية موازنة خارجية من إدارة عدة موجهات (routers) تستضيف بشكل شفاف وجهة واحدة <a href="../../ar/docs/specs/common-structures/#destination">Destination</a> .</p> <p>حاليًا لا يحدد هذا الاقتراح تنفيذًا ملموسًا. يمكن تنفيذه كامتداد لـ <a href="../../ar/docs/specs/i2cp/">I2CP</a> ، أو كبروتوكول جديد.</p> <h2 id="الدوافع">الدوافع</h2> <p>&ldquo;المُضيف المتعدد&rdquo; (Multihoming) هو استخدام عدة موجهات لاستضافة نفس الوجهة. الطريقة الحالية لتحقيق المُضيف المتعدد في I2P هي تشغيل نفس الوجهة على كل موجه بشكل مستقل؛ والموجه الذي يستخدمه العملاء في أي وقت معين هو آخر موجه نشر مجموعة تأجير (LeaseSet).</p>/ar/proposals/100-restricted-routes/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/100-restricted-routes/<h2 id="المقدمة">المقدمة</h2> <h2 id="الأفكار">الأفكار</h2> <ul> <li> <p>إضافة نقل جديد &ldquo;IND&rdquo; (غير مباشر) ينشر تجزئة leaseSet في بنية RouterAddress: &ldquo;IND: [key=aababababababababb]&rdquo;. يُقدم هذا النقل أدنى أولوية عندما يقوم جهاز التوجيه المستهدف بنشره. لإرسالها إلى نظير عبر هذا النقل، قم باستخراج leaseset من نظير ff كما هو معتاد، وأرسلها مباشرة إلى الإيجار.</p> </li> <li> <p>يجب على أي نظير يعلن عن IND بناء وصيانة مجموعة من الأنفاق إلى نظير آخر. هذه ليست أنفاق استكشافية وليست أنفاق عملاء، بل مجموعة ثانية من أنفاق جهاز التوجيه.</p>/ar/proposals/133-introducer-expiration/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/133-introducer-expiration/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تتعلق هذه المقترح بتحسين معدل نجاح عمليات التعريف (introductions).</p> <h2 id="الدوافع">الدوافع</h2> <p>تنتهي صلاحية أجهزة التعريف (introducers) بعد فترة زمنية معينة، ولكن هذه المعلومة لا تُنشر في معلومات الراوتر (Router Info). يجب حاليًا على الراوترات استخدام أساليب تقديرية (heuristics) لتخمين ما إذا كان جهاز التعريف لم يعد صالحًا.</p> <h2 id="التصميم">التصميم</h2> <p>في عنوان راوتر SSU يحتوي على أجهزة تعريف، يمكن للناشر تضمين أوقات انتهاء الصلاحية لكل جهاز تعريف بشكل اختياري.</p> <h2 id="المواصفات">المواصفات</h2> <pre tabindex="0"><code>iexp{X}={nnnnnnnnnn} X :: رقم جهاز التعريف (0-2) nnnnnnnnnn :: الوقت بالثواني (ليس بالميلي ثانية) منذ بداية العصر (epoch). </code></pre><h3 id="ملاحظات">ملاحظات</h3> <ul> <li> <p>يجب أن يكون كل وقت انتهاء صلاحية أكبر من تاريخ نشر معلومات الراوتر (Router Info)، وأقل من 6 ساعات بعد تاريخ النشر.</p>/ar/proposals/154-ecies-lookups/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/154-ecies-lookups/<h2 id="ملاحظة">ملاحظة</h2> <p>تم تنفيذ ECIES إلى ElG في الإصدار 0.9.46 وتمت إغلاق مرحلة الاقتراح. انظر <a href="../../ar/docs/specs/i2np/">I2NP</a> للحصول على المواصفات الرسمية. قد يتم الرجوع إلى هذا الاقتراح للحصول على معلومات خلفية. تم تنفيذ ECIES إلى ECIES مع تضمين المفاتيح بدءاً من الإصدار 0.9.48. قد يتم إعادة فتح قسم ECIES-to-ECIES (المفاتيح المشتقة) أو دمجه في اقتراح مستقبلي.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <h3 id="تعاريف">تعاريف</h3> <ul> <li>AEAD: ChaCha20/Poly1305</li> <li>DLM: رسالة بحث قاعدة بيانات I2NP</li> <li>DSM: رسالة تخزين قاعدة بيانات I2NP</li> <li>DSRM: رسالة رد بحث قاعدة بيانات I2NP</li> <li>ECIES: ECIES-X25519-AEAD-Ratchet (الاقتراح 144)</li> <li>ElG: ElGamal</li> <li>ENCRYPT(k, n, payload, ad): كما هو معرّف في <a href="../../ar/docs/specs/ecies/">ECIES</a> </li> <li>LS: مجموعة التأجير</li> <li>lookup: رسالة DLM لـ I2NP</li> <li>reply: DSM أو DSRM لـ I2NP</li> </ul> <h3 id="الملخص">الملخص</h3> <p>عند إرسال DLM لمجموعة تأجير إلى floodfill، فإن DLM يحدد بشكل عام أن الرد يكون موسومًا، مشفرًا بـ AES، ويتم إرساله عبر نفق إلى الوجهة. تم إضافة دعم الردود المشفرة بـ AES في الإصدار 0.9.7.</p>/ar/proposals/163-datagram2/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/163-datagram2/<h2 id="الحالة">الحالة</h2> <p>تمت الموافقة في المراجعة بتاريخ 2025-04-15. تم دمج التغييرات في المواصفات. تم تنفيذها في Java I2P اعتبارًا من API 0.9.66. راجع وثائق التنفيذ للحصول على الحالة.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>خرجت من <a href="../../ar/proposals/123-new-netdb-entries/">Prop123</a> كتقديم منفصل.</p> <p>لا يمكن التحقق من التوقيعات غير المتصلة في معالجة مخطط البيانات القابلة للاسترجاع. يحتاج إلى علم للإشارة إلى توقيع غير متصل ولكن لا يوجد مكان لوضع علم.</p> <p>سيتطلب بروتوكول I2CP جديد تمامًا ورقم تنسيق، ليتم إضافته إلى مواصفات <a href="../../ar/docs/api/datagrams/">DATAGRAMS</a> . دعونا نسميه &ldquo;Datagram2&rdquo;.</p>/ar/proposals/150-garlic-farm-protocol/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/150-garlic-farm-protocol/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا هو المواصفة الخاصة ببروتوكول الاتصال &ldquo;Garlic Farm&rdquo;، والمبنية على JRaft، ورمز &ldquo;exts&rdquo; الخاص بها للتنفيذ عبر TCP، وتطبيقها النموذجي &ldquo;dmprinter&rdquo; <a href="https://github.com/datatechnology/jraft">JRAFT</a> .</p> <p>لم نتمكن من العثور على أي تنفيذ يحتوي على بروتوكول اتصال موثق. ومع ذلك، فإن تنفيذ JRaft بسيط بما يكفي لأن نفحص الكود ثم نوثق بروتوكوله. هذا الاقتراح هو نتيجة لذلك الجهد.</p> <p>سيكون هذا هو الطريقة الخلفية لتنسيق الراوترات التي تنشر إدخالات في Meta LeaseSet. انظر الاقتراح 123.</p>/ar/proposals/169-pq-crypto/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/169-pq-crypto/<h3 id="الحالة">الحالة</h3> <table> <thead> <tr> <th>البروتوكول / الميزة</th> <th>الحالة</th> </tr> </thead> <tbody> <tr> <td>Ratchet</td> <td>مكتمل في Java I2P و i2pd</td> </tr> <tr> <td>NTCP2</td> <td>بيتا الربع الأول 2026</td> </tr> <tr> <td>SSU2</td> <td>بدء التنفيذ قريباً، بيتا الربع الثالث 2026</td> </tr> <tr> <td>MLDSA SigTypes</td> <td>أولوية منخفضة، على الأرجح 2027+</td> </tr> </tbody> </table> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>بينما استمر البحث والمنافسة للحصول على تشفير ما بعد الكم (PQ) المناسب لعقد من الزمن، لم تصبح الخيارات واضحة حتى وقت قريب.</p> <p>بدأنا في النظر إلى تأثيرات التشفير المقاوم للكم (PQ crypto) في عام 2022 <a href="http://zzz.i2p/topics/3294">zzz.i2p</a> .</p> <p>أضافت معايير TLS دعم التشفير المختلط في العامين الماضيين وأصبحت الآن تُستخدم لجزء كبير من حركة البيانات المشفرة على الإنترنت بسبب الدعم في Chrome و Firefox <a href="https://blog.cloudflare.com/pq-2024/">Cloudflare</a> .</p>/ar/proposals/115-batch-multiple-data-cloves-in-garlic/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/115-batch-multiple-data-cloves-in-garlic/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>يتعلق هذا الاقتراح بإرسال فصوص ثوم بيانات متعددة داخل رسالة ثوم من طرف إلى طرف، بدلاً من واحدة فقط.</p> <h2 id="الدافع">الدافع</h2> <p>غير واضح.</p> <h2 id="التغييرات-المطلوبة">التغييرات المطلوبة</h2> <p>يجب أن تكون التغييرات في OCMOSJ والصفوف المساعدة ذات الصلة، وفي ClientMessagePool. ولأنه لا يوجد الآن طابور، سيكون ضرورياً إنشاء طابور جديد وبعض التأخير. أي تجميع يجب أن يلتزم بحجم ثوم أقصى لتقليل الإسقاط. ربما 3 كيلوبايت؟ سيكون من المفيد قياس الأمور أولاً لتحديد مدى استخدام هذا الأمر.</p>/ar/proposals/164-streaming/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/164-streaming/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>أجهزة توجيه Java I2P وi2pd الأقدم من API 0.9.58 (تم إصدارها في مارس 2023) معرضة لهجوم إعادة تشغيل حزم SYN للبث. هذه مشكلة في تصميم البروتوكول، وليست خطأ في التنفيذ.</p> <p>يتم توقيع حزم SYN، لكن توقيع حزمة SYN الأساسية المرسلة من أليس إلى بوب غير مرتبط بهوية بوب، لذا قد يُخزّن بوب تلك الحزمة ويعيد تشغيلها، ويرسلها إلى ضحية تشارلي. سيفكر تشارلي أن الحزمة جاءت من أليس ويرد عليها. في معظم الحالات، هذا غير ضار، ولكن قد تحتوي حزمة SYN على بيانات أساسية (مثل GET أو POST) ستقوم تشارلي بمعالجتها على الفور.</p>/ar/proposals/158-ipv6-transport-enhancements/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/158-ipv6-transport-enhancements/<h2 id="ملاحظة">ملاحظة</h2> <p>النشر والاختبار على الشبكة قيد التقدم. خاضع لتعديلات طفيفة.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>يهدف هذا الاقتراح إلى تنفيذ تحسينات على وسائط النقل SSU وNTCP2 لدعم IPv6.</p> <h2 id="الدافع">الدافع</h2> <p>مع تزايد انتشار IPv6 حول العالم، وشيوع الإعدادات التي تعتمد على IPv6 فقط (خاصةً على الأجهزة المحمولة)، نحتاج إلى تحسين دعمنا لبروتوكول IPv6 وإزالة الافتراضات القائلة بأن جميع الراوترات تدعم IPv4.</p> <h3 id="التحقق-من-الاتصال">التحقق من الاتصال</h3> <p>عند اختيار الأقران للأنفاق، أو اختيار مسارات OBEP/IBGW لتوجيه الرسائل، يساعد حساب ما إذا كان يمكن للراوتر A الاتصال بالراوتر B. بشكل عام، يعني هذا تحديد ما إذا كان لدى A إمكانية إرسال خارجية عبر وسيلة نقل ونوع عنوان (IPv4/v6) يتطابق مع أحد عناوين B الواردة المعلنة.</p>/ar/proposals/105-garlicat-name-translation/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/105-garlicat-name-translation/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح يدور حول إضافة دعم للبحث العكسي لنظام أسماء النطاقات (DNS) إلى I2P.</p> <h2 id="آلية-الترجمة-الحالية">آلية الترجمة الحالية</h2> <p>يقوم GarliCat (GC) بترجمة الأسماء لإعداد الاتصالات مع عقد أخرى لـ GC. هذه الترجمة للأسماء هي مجرد ترميز للتمثيل الثنائي لعناوين إلى شكل مشفر بـ Base32. لذا، فإن الترجمة تعمل ذهاباً وإياباً.</p> <p>يتم اختيار هذه العناوين بحيث تكون بطول 80 بت. هذا لأن Tor يستخدم قيم بطول 80 بت لعنونه خدماته المخفية. لذا، يعمل OnionCat (والذي هو GC لـ Tor) مع Tor بدون تدخل إضافي.</p>/ar/proposals/125-obep-to-one-of-many-tunnels/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/125-obep-to-one-of-many-tunnels/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>يغطي هذا الاقتراح تحسينين لتحسين أداء الشبكة:</p> <ul> <li> <p>تفويض اختيار IBGW إلى OBEP من خلال تزويده بقائمة من البدائل بدلاً من خيار واحد فقط.</p> </li> <li> <p>تمكين توجيه الحزم متعددة البث (multicast) في OBEP.</p> </li> </ul> <h2 id="الدوافع">الدوافع</h2> <p>في حالة الاتصال المباشر، الفكرة هي تقليل ازدحام الاتصال، من خلال منح OBEP مرونة في كيفية اتصاله بـ IBGWs. القدرة على تحديد نفق متعدد تمكننا أيضًا من تنفيذ البث المتعدد في OBEP (من خلال توصيل الرسالة إلى جميع الأنفاق المحددة).</p>/ar/proposals/153-chacha20-layer-encryption/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/153-chacha20-layer-encryption/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>يستند هذا الاقتراح ويتطلب التغييرات من الاقتراح 152: أنفاق ECIES.</p> <p>فقط الأنفاق المبنية من خلال القفزات التي تدعم صيغة BuildRequestRecord لأنفاق ECIES-X25519 يمكنها تنفيذ هذه المواصفات.</p> <p>تتطلب هذه المواصفات تنسيق خيارات بناء النفق للإشارة إلى نوع تشفير طبقة النفق ونقل مفاتيح طبقة AEAD.</p> <h3 id="الأهداف">الأهداف</h3> <p>الأهداف من هذا الاقتراح هي:</p> <ul> <li>استبدال AES256/ECB+CBC بـChaCha20 لتشفير طبقة النفق المثبتة وIV</li> <li>استخدام ChaCha20-Poly1305 لحماية AEAD بين القفزات</li> <li>عدم الكشف عن تشفير طبقة النفق القائم للمشاركين غير المشتركين في النفق</li> <li>عدم إجراء أي تغييرات على طول الرسائل العلوية للنفق</li> </ul> <h3 id="معالجة-الرسائل-المثبتة-في-النفق">معالجة الرسائل المثبتة في النفق</h3> <p>هذا القسم يصف التغييرات على:</p>/ar/proposals/151-ecdsa-blinding/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/151-ecdsa-blinding/<h2 id="الدافع">الدافع</h2> <p>بعض الأشخاص لا يحبون EdDSA أو RedDSA. يجب أن نقدم بعض البدائل ونسمح لهم بتعمية التوقيعات في ECDSA.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>تصف هذه الاقتراح كيفية تعمية المفاتيح لأنواع التوقيع في ECDSA 1، 2، 3.</p> <h2 id="الاقتراح">الاقتراح</h2> <p>يعمل بنفس طريقة RedDSA، لكن كل شيء باللغة النهاية الكبيرة. يُسمح فقط بنفس أنواع التوقيع، مثل 1-&gt;1، 2-&gt;2، 3-&gt;3.</p> <h3 id="التعريفات">التعريفات</h3> <p>B نقطة الأساس في المنحنى</p> <p>L ترتيب مجموعة المنحنى البيضوي. خاصية المنحنى.</p> <p>DERIVE_PUBLIC(a) تحويل مفتاح خاص إلى عام، عبر ضرب B على منحنى بيضوي</p>/ar/proposals/116-prefer-near-in-keyspace/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/116-prefer-near-in-keyspace/<h2 id="النظرة-العامة">النظرة العامة</h2> <p>هذا اقتراح لتنظيم الأقران بحيث يفضلون الاتصال بأقران آخرين قريبين منهم في المساحة المفتاحية.</p> <h2 id="الدافع">الدافع</h2> <p>الفكرة هي تحسين نجاح بناء النفق، بزيادة احتمال أن يكون جهاز التوجيه متصلًا بالفعل بجهاز آخر.</p> <h2 id="التصميم">التصميم</h2> <h3 id="التغييرات-المطلوبة">التغييرات المطلوبة</h3> <p>سيتطلب هذا التغيير:</p> <ol> <li>يفضل كل جهاز توجيه الاتصالات القريبة منهم في المساحة المفتاحية.</li> <li>يكون كل جهاز توجيه على علم بأن كل جهاز توجيه يفضل الاتصالات القريبة منهم في المساحة المفتاحية.</li> </ol> <h3 id="مزايا-لبناء-الأنفاق">مزايا لبناء الأنفاق</h3> <p>إذا قمت ببناء نفق:</p>/ar/proposals/170-i2pcontrol-expansion/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/170-i2pcontrol-expansion/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>يُقدِّم هذا الاقتراح معلومات جديدة إلى واجهة برمجة تطبيقات i2pcontrol، مما يتيح مرونة أكبر. تشمل هذه المعلومات: إضافة وحذف واسترجاع وتعديل دفاتر العناوين والخدمات المخفية. كما يُقدِّم هذا الاقتراح مزيدًا من المعلومات حول جهاز التوجيه الخاص بك، مثل الأقران (peers) والأخبار (news) وقاعدة البيانات الشبكية (netdb) والمزيد.</p> <h2 id="الدافع">الدافع</h2> <p>حالة الاستخدام لهذا الاقتراح هي إنشاء واجهة وحدة تحكم موحدة وبسيطة يمكن مشاركتها عبر كل تنفيذات الراوتر مع مجموعة البروتوكولات القياسية لشبكة i2p. وبشكل أساسي، يتيح هذا الاقتراح تجربة أكثر بديهية وسهولة في الاستخدام للمستخدمين عبر شبكة I2P.</p>/ar/proposals/117-opt-in-statistics-collection/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/117-opt-in-statistics-collection/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تتعلق هذه الاقتراح بنظام الإبلاغ الآلي الذي يتم الاشتراك فيه لجمع إحصاءات الشبكة.</p> <h2 id="الدافع">الدافع</h2> <p>حاليًا، هناك العديد من معلمات الشبكة التي تم تحديدها استنادًا إلى التخمين المستنير. يُشتبه في أن بعضها يمكن تعديله لتحسين الأداء العام للشبكة من حيث السرعة والموثوقية وغيرها. ومع ذلك، فإن تغييرها دون بحث مناسب يعتبر محفوفًا بالمخاطر للغاية.</p> <h2 id="التصميم">التصميم</h2> <p>يدعم الموجه جمع واسع للإحصاءات التي يمكن استخدامها لتحليل خصائص الشبكة بشكل عام. ما نحتاجه هو نظام إبلاغ آلي يجمع تلك الإحصاءات في مكان مركزي. بطبيعة الحال، سيكون ذلك اختياريًا لأنه يدمر بشكل كبير الهوية المجهولة. (الإحصاءات الصديقة للخصوصية تُبلّغ بالفعل إلى stats.i2p) كرقم تقريبي، لشبكة بحجم 30,000 ينبغي أن يكون عينة من 300 موجه إبلاغ ممثلة بشكل كافٍ.</p>/ar/proposals/162-congestion-caps/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/162-congestion-caps/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>إضافة مؤشرات ازدحام إلى معلومات الموجه المنشورة (RI).</p> <h2 id="الدافع">الدافع</h2> <p>تشير &ldquo;حدود&rdquo; عرض النطاق الترددي (القدرات) إلى حدود مشاركة عرض النطاق وإمكانات الوصول ولكن لا تشير إلى حالة الازدحام. سيساعد مؤشر الازدحام الموجهات في تجنب محاولة البناء عبر موجه مزدحم، مما يؤدي إلى مزيد من الازدحام وتخفيض نجاح بناء النفق.</p> <h2 id="التصميم">التصميم</h2> <p>تعريف قدرات جديدة للإشارة إلى مستويات مختلفة من الازدحام أو مشاكل السعة. سيتم وضعها في قدرات RI العلوية، وليس قدرات العنوان.</p>/ar/proposals/143-build-message-options/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/143-build-message-options/<h2 id="ملاحظة">ملاحظة</h2> <p>لم يتم تنفيذ هذا الاقتراح كما هو محدد، ومع ذلك، تم تصميم رسائل البناء الطويلة والقصيرة ل ECIES (الاقتراحات 152 و 157) بحقول خيارات قابلة للتمديد. انظر <a href="../../ar/docs/specs/tunnel-implementation/#tunnel-creation-ecies">مواصفة Tunnel Creation ECIES</a> للمواصفة الرسمية.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>إضافة آلية مرنة وقابلة للتمديد للخيارات في سجلات بناء I2NP Tunnel والتي تحتوي عليها رسائل بناء النفق والرد على بناء النفق.</p> <h2 id="الدافع">الدافع</h2> <p>هناك بعض الاقتراحات المؤقتة الغير موثقة التي يتم تقديمها لتعيين الخيارات أو التكوين في رسالة بناء النفق، بحيث يمكن لمنشئ النفق تمرير بعض المعلمات إلى كل مرحلة من مراحل النفق.</p>/ar/proposals/137-optional-sigtypes/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/137-optional-sigtypes/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>إضافة طريقة تمكن floodfills من الإعلان عن دعمها لأنواع التوقيعات الاختيارية. سيتيح ذلك توفير طريقة لدعم أنواع توقيعات جديدة على المدى الطويل، حتى لو لم تدعم جميع التطبيقات هذه الأنواع.</p> <h2 id="الدافع">الدافع</h2> <p>كشفت اقتراح GOST رقم 134 عن عدة مشكلات مع نطاق التوقيع التجريبي غير المستخدم سابقًا.</p> <p>أولاً، بما أن أنواع التوقيعات في النطاق التجريبي لا يمكن حجزها، فقد تُستخدم لأنواع توقيعات متعددة دفعة واحدة.</p> <p>ثانيًا، ما لم يمكن تخزين معلومات الموجه أو مجموعة التأجير بنوع توقيع تجريبي في floodfill، سيكون من الصعب اختبار النوع الجديد من التوقيعات بالكامل أو استخدامه بشكل تجريبي.</p>/ar/proposals/136-experimental-sigtypes/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/136-experimental-sigtypes/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>بالنسبة لأنواع التوقيع في النطاق التجريبي (65280-65534)، يجب على الفيضانات قبول تخزين netdb دون التحقق من التوقيع.</p> <p>سوف يدعم هذا اختبار أنواع التوقيع الجديدة.</p> <h2 id="الدافع">الدافع</h2> <p>اقتراح GOST 134 كشف عن مشكلتين مع نطاق نوع التوقيع التجريبي غير المستخدم سابقًا.</p> <p>أولاً، نظرًا لأن أنواع التوقيع في النطاق التجريبي لا يمكن الاحتفاظ بها، قد تُستخدم لأنواع توقيع متعددة في وقت واحد.</p> <p>ثانيًا، ما لم يتم تخزين معلومات الموجه أو مجموعة التأجير مع نوع توقيع تجريبي في الفيضانات، فإن نوع التوقيع الجديد يكون من الصعب اختباره بالكامل أو استخدامه على أساس تجريبي.</p>/ar/proposals/102-service-directory/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/102-service-directory/<h2 id="لمحة-عامة">لمحة عامة</h2> <p>هذا الاقتراح يتعلق ببروتوكول يمكن أن تستخدمه التطبيقات لتسجيل والخدمات في دليل.</p> <h2 id="الدافع">الدافع</h2> <p>الطريقة الأكثر مباشرة لدعم onioncat هي باستخدام دليل الخدمة.</p> <p>هذا مشابه لاقتراح كان لسبونج قبل فترة على الـ IRC. لا أعتقد أنه كتبه، لكن فكرته كانت وضعه في netDb. لست مؤيدًا لذلك، لكن سأترك المناقشة حول أفضل طريقة للوصول إلى الدليل (عمليات البحث في netDb، DNS-over-i2p، HTTP، hosts.txt، إلخ) ليوم آخر.</p> <p>ربما يمكنني إعداد ذلك بسرعة باستخدام HTTP ومجموعة من سكربتات البيرل التي أستخدمها لنموذج إضافة المفتاح.</p>/ar/proposals/103-bigger-i2np-messages/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/103-bigger-i2np-messages/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح يتعلق بزيادة الحد الأقصى لحجم رسائل I2NP.</p> <h2 id="الدافع">الدافع</h2> <p>استخدام iMule لحزم بيانات بحجم 12 كيلو بايت كشف عن الكثير من المشاكل. الحد الفعلي اليوم هو أقرب إلى 10 كيلو بايت.</p> <h2 id="التصميم">التصميم</h2> <p>للقيام بـ:</p> <ul> <li> <p>زيادة حد NTCP - ليس بالأمر السهل؟</p> </li> <li> <p>المزيد من التعديلات على كمية علامات الجلسة. قد يؤثر على الحد الأقصى لحجم النافذة؟ هل هناك إحصاءات يمكن النظر إليها؟ جعل الرقم متغير بناءً على الكمية التي نعتقد أنهم يحتاجونها؟ هل يمكنهم طلب المزيد؟ طلب كمية؟</p>/ar/proposals/157-new-tbm/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/157-new-tbm/<h2 id="ملاحظة">ملاحظة</h2> <p>تم تنفيذها اعتبارًا من الإصدار API 0.9.51. جاري نشرها واختبارها على الشبكة. عرضة للمراجعة الطفيفة. انظر <a href="../../ar/docs/specs/i2np/">I2NP</a> و<a href="../../ar/docs/specs/tunnel-implementation/#tunnel-creation-ecies">Tunnel-Creation-ECIES</a> للمواصفات النهائية.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <h3 id="الملخص">الملخص</h3> <p>الحجم الحالي للسجلات المشفرة لطلب بناء النفق والسجلات في الرد هو 528 بايت. بالنسبة لرسائل بناء النفق المتغيرة والردود على بناء النفق، يكون الحجم الإجمالي 2113 بايت. يتم تقسيم هذه الرسالة إلى ثلاثة رسائل أنفاق لكل منها 1 كيلوبايت للمسار العكسي.</p> <p>التغييرات على سجل بحجم 528 بايت لأجهزة التوجيه ECIES-X25519 محددة في <a href="../../ar/proposals/152-ecies-tunnels/">Prop152</a> و<a href="../../ar/docs/specs/tunnel-implementation/#tunnel-creation-ecies">Tunnel-Creation-ECIES</a> . بالنسبة لمزيج من أجهزة التوجيه ElGamal وECIES-X25519 في نفق، يجب أن يظل حجم السجل 528 بايت. ومع ذلك، إذا كانت جميع أجهزة التوجيه في نفق هي ECIES-X25519، فمن الممكن إنشاء سجل بناء أصغر، لأن تشفير ECIES-X25519 لديه عبء منخفض كثيرا مقارنة بـ ElGamal.</p>/ar/proposals/131-dormant-fee-addressbook/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/131-dormant-fee-addressbook/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>إذا كان العنوان غير متصل لفترة طويلة، يجب إزالته من دفتر العناوين ليصبح الاسم متاحًا لتسجيل جديد. هذا هو الحال الآن في كيفية عمل inr.</p> <p>لكن ماذا إذا لم يكن المالك مهتمًا بتشغيل هذه المورد بعد الآن ولكنه يريد الاحتفاظ بعنوان له لتجنب الاحتيال، إلخ. يجب أن نقدم رسومًا سنوية. سيظل العنوان في السجلات طالما تم دفع الرسوم. لن تكون هناك حاجة لأي رسوم إذا كان قد عاد للعمل عبر الإنترنت. في حالة stats.i2p، يجب أن تذهب الأموال إلى ميزانية I2P.</p>/ar/proposals/127-increase-ipv6-mtu/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/127-increase-ipv6-mtu/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تهدف هذه المقترح إلى زيادة الحد الأقصى ل SSU IPv6 MTU من 1472 إلى 1488. تم تطبيقه في الإصدار 0.9.28.</p> <h2 id="الدافع">الدافع</h2> <p>يجب أن يكون IPv4 MTU مضاعفاً لـ16، + 12. يجب أن يكون IPv6 MTU مضاعفاً لـ16.</p> <p>عندما تمت إضافة دعم IPv6 لأول مرة منذ سنوات، قمنا بتعيين الحد الأقصى ل IPv6 MTU إلى 1472، أقل من IPv4 MTU البالغ 1484. كان ذلك لتبسيط الأمور وضمان أن يكون IPv6 MTU أقل من IPv4 MTU الموجود. الآن وبعد أن أصبح دعم IPv6 مستقراً، يجب أن نتمكن من تعيين IPv6 MTU أعلى من IPv4 MTU.</p>/ar/proposals/167-service-records/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/167-service-records/<h2 id="الحالة">الحالة</h2> <p>تمت الموافقة في المراجعة الثانية بتاريخ 2025-04-01؛ المواصفات محدثة؛ لم يتم تنفيذها بعد.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>يخلو I2P من نظام DNS مركزي. ومع ذلك، فإن دفتر العناوين، جنبًا إلى جنب مع نظام اسم المضيف b32، يسمح للموجه بالبحث عن وجهات كاملة واسترجاع مجموعات التأجير (lease sets)، التي تحتوي على قائمة من البوابات والمفاتيح بحيث يمكن للعملاء الاتصال بتلك الوجهة.</p> <p>إذًا، تشبه مجموعات التأجير (leasesets) سجلات DNS نوعًا ما. لكن حاليًا لا توجد وسيلة لمعرفة ما إذا كان هذا المضيف يدعم أي خدمات، سواء على تلك الوجهة أو غيرها، بطريقة مشابهة لسجلات DNS <a href="https://en.wikipedia.org/wiki/SRV_record">SRV</a> كما هو محدد في <a href="https://datatracker.ietf.org/doc/html/rfc2782">RFC 2782</a> .</p>/ar/proposals/128-quasi-dns/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/128-quasi-dns/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح هو استخدام DNS عبر الرزم الفرعية للنطاقات الفرعية.</p> <h2 id="الدوافع">الدوافع</h2> <p>سيتم تحديدها</p> <h2 id="التصميم">التصميم</h2> <p>سيتم تحديدها</p> <h2 id="المواصفة">المواصفة</h2> <p>سيتم تحديدها</p> <h2 id="الترحيب">الترحيب</h2> <p>سيتم تحديدها</p>/ar/proposals/171-i2cp-streaming-ack-tunnel-switch/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/171-i2cp-streaming-ack-tunnel-switch/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>يمكن أن تتوقف اتصالات العميل في البث عندما تُفقد تأكيدات التسليم بصمت. يقوم المرسل بإعادة الإرسال حتى يتم استلام تأكيد أو حتى يتم قطع الاتصال، دون وجود وسيلة موثوقة للتحقق من وصول التأكيدات إلى الطرف الآخر. يضيف هذا الاقتراح بتة علامة جديدة إلى حقل العلامات في <a href="../../ar/docs/specs/i2cp/">SendMessageExpiresMessage</a> بحيث يمكن للعميل أن يوجه الموجه باختيار نفق صادر مختلف للرسائل اللاحقة لنفس الوجهة. يستخدم بروتوكول البث هذه البتة لبدء تبديل النفق عند اكتشاف توقف الاتصال.</p>/ar/proposals/001-process/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/001-process/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>يصف هذا المستند كيفية تغيير مواصفات I2P، وكيفية عمل مقترحات I2P، والعلاقة بين مقترحات I2P والمواصفات.</p> <p>تم تعديل هذا المستند من عملية مقترح Tor، وكثير من المحتوى أدناه تم كتابته في الأصل بواسطة Nick Mathewson.</p> <p>هذا هو مستند إعلامي.</p> <h2 id="الدافع">الدافع</h2> <p>في السابق، كانت عملية تحديث مواصفات I2P غير رسمية إلى حد ما: كنا نقدم مقترحًا على منتدى التطوير ونناقش التغييرات، ثم نصل إلى إجماع ونقوم بتعديل المواصفة مع تغييرات مسودة (ليس بالضرورة في ذلك الترتيب)، وأخيرًا ننفذ التغييرات.</p>/ar/proposals/130-blocklist-su3/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/130-blocklist-su3/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح هو لتوزيع تحديثات قوائم الحظر في ملف su3 منفصل.</p> <h2 id="الدافع">الدافع</h2> <p>بدون هذا، يتم تحديث قائمة الحظر فقط في الإصدار. يمكن استخدام هذا التنسيق في تطبيقات متعددة لجهاز التوجيه.</p> <h2 id="التصميم">التصميم</h2> <p>تحديد الشكل ليتم تغليفه في ملف su3. السماح بالحظر بواسطة عنوان IP أو تجزئة جهاز التوجيه. يمكن لأجهزة التوجيه الاشتراك في عنوان URL، أو استيراد ملف تم الحصول عليه بوسائل أخرى. يحتوي ملف su3 على توقيع يجب التحقق منه عند الاستيراد.</p>/ar/proposals/129-blocklist-newsxml/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/129-blocklist-newsxml/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تهدف هذه الاقتراح إلى توزيع تحديثات قائمة الحظر في ملف الأخبار، الذي يتم توزيعه بتنسيق su3 الموقع. تم تنفيذه في الإصدار 0.9.28.</p> <h2 id="الدافع">الدافع</h2> <p>بدون هذا، لا يتم تحديث قائمة الحظر إلا في الإصدار. يستخدم اشتراك الأخبار الحالي. يمكن استخدام هذا التنسيق في تطبيقات توجيه مختلفة، ولكن فقط برنامج التوجيه Java يستخدم اشتراك الأخبار الآن.</p> <h2 id="التصميم">التصميم</h2> <p>إضافة قسم جديد إلى ملف news.xml. السماح بالحظر عبر IP أو تجزئة الموجه. سيكون للقسم ختم زمني خاص به. السماح بإلغاء حظر الإدخالات المحجوبة سابقًا.</p>/ar/proposals/142-new-crypto-template/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/142-new-crypto-template/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>يصف هذا المستند القضايا المهمة التي يجب أخذها بعين الاعتبار عند اقتراح بديل أو إضافة إلى تشفير ElGamal غير المتماثل المستخدم لدينا.</p> <p>هذا مستند إعلامي.</p> <h2 id="الدوافع">الدوافع</h2> <p>تُعد خوارزمية ElGamal قديمة وبطيئة، ووجود بدائل أفضل.<br> مع ذلك، هناك عدة قضايا يجب معالجتها قبل أن نتمكن من إضافة أو التحول إلى أي خوارزمية جديدة.<br> يسلط هذا المستند الضوء على هذه القضايا غير المحلولة.</p> <h2 id="البحث-الخلفي">البحث الخلفي</h2> <p>على أي شخص يقترح تشفيرًا جديدًا أن يكون على دراية أولًا بالمستندات التالية:</p>/ar/proposals/160-udp-trackers/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/160-udp-trackers/<h2 id="الحالة">الحالة</h2> <p>تمت الموافقة عليه في المراجعة 2025-06-24. المواصفة متوفرة في <a href="../../ar/docs/specs/udp-bittorrent-announces/">مواصفة UDP</a> . مُنفذ في zzzot 0.20.0-beta2. مُنفذ في i2psnark اعتباراً من API 0.9.67. تحقق من وثائق التنفيذات الأخرى للحالة.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح مخصص لتطبيق UDP trackers في I2P.</p> <h3 id="change-history">Change History</h3> <p>تم نشر اقتراح أولي لمتتبعات UDP في I2P على <a href="../../ar/docs/applications/bittorrent/">صفحة مواصفات bittorrent</a> الخاصة بنا في مايو 2014؛ وقد سبق هذا عملية الاقتراح الرسمية لدينا، ولم يتم تنفيذه قط. تم إنشاء هذا الاقتراح في أوائل عام 2022 ويبسط نسخة 2014.</p>/ar/proposals/121-encrypted-leaseset/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/121-encrypted-leaseset/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح يتعلق بإعادة تصميم آليّة تشفير LeaseSets.</p> <h2 id="الدافع">الدافع</h2> <p>LeaseSet المشفرة الحالية سيئة للغاية وغير آمنة. يمكنني القول ذلك، لقد قمت بتصميمها وتنفيذها.</p> <p>الأسباب:</p> <ul> <li>مشفرة باستخدام AES CBC</li> <li>مفتاح AES واحد للجميع</li> <li>انتهاء صلاحية Lease مازالت مكشوفة</li> <li>مفتاح التشفير العام مازال مكشوفا</li> </ul> <h2 id="التصميم">التصميم</h2> <h3 id="الأهداف">الأهداف</h3> <ul> <li>جعل الشيء كله غامضا</li> <li>مفاتيح لكل مستلم</li> </ul> <h3 id="الاستراتيجية">الاستراتيجية</h3> <p>افعل مثل GPG/OpenPGP. تشفير مفتاح متعظم بشكل غير متماثل لكل مستلم. البيانات مشفرة باستخدام ذلك المفتاح غير المتماثل. انظر على سبيل المثال <a href="https://tools.ietf.org/html/rfc4880#section-5.1">RFC-4880-S5.1</a> إذا كنا نستطيع أن نجده خوارزمية صغيرة وسريعة.</p>/ar/proposals/120-meta-leaseset-for-multihoming/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/120-meta-leaseset-for-multihoming/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تهدف هذه الاقتراح إلى تنفيذ دعم صحيح لتعدد المواضع في I2P يمكنه التوسع إلى مواقع كبيرة.</p> <h2 id="الدافع">الدافع</h2> <p>يعتبر تعدد المواضع حلاً مؤقتاً وعلى الأرجح لن يعمل، على سبيل المثال، مع facebook.i2p بمقياس كبير. لنفترض أن لدينا 100 مواضع متعددة كل منها يحتوي على 16 نفقاً، هذا يعني 1600 نشرة LS كل 10 دقائق، أو ما يقرب من 3 في الثانية. ستُغمر الفيضانات وستبدأ أدوات التحكم في الضغط. وهذا قبل أن نذكر حتى ترافيك البحث.</p>/ar/proposals/135-authenticated-address-helpers/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/135-authenticated-address-helpers/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تضيف هذه الاقتراح آلية توثيق إلى روابط مساعد العناوين.</p> <h2 id="الدافع">الدافع</h2> <p>روابط مساعد العناوين بطبيعتها غير آمنة. بإمكان أي شخص وضع معلمة مساعد العناوين في رابط، حتى مع صورة، ويمكنه وضع أي وجهة في معلمة URL لمساعد العنوان &ldquo;i2paddresshelper&rdquo;. اعتماداً على تنفيذ وكيل HTTP للمستخدم، قد يتم قبول خريطة الاسم المضيف/الوجهة هذه، إذا لم تكن موجودة حالياً في دفتر العناوين، سواءً بوجود شاشة وسيطة للمستخدم للقبول أو بدونها.</p> <h2 id="التصميم">التصميم</h2> <p>سوف تقدم خوادم القفز الموثوقة وخدمات تسجيل دفاتر العناوين روابط جديدة لمساعد العنوان تضيف معلمات توثيق. ستتكون المعلمتان الجديدتان من توقيع Base 64 وسلسلة موقعة بواسطة.</p>/ar/proposals/138-match-obep-with-ibgw/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/138-match-obep-with-ibgw/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>تضيف هذه الاقتراحية خيار I2CP للأنفاق الصادرة الذي يتسبب في اختيار أو بناء الأنفاق عند إرسال رسالة بحيث يتطابق OBEP مع أحد IBGWs من LeaseSet للوجهة Destination المستهدفة.</p> <h2 id="الدافع">الدافع</h2> <p>تستخدم معظم موجهات I2P نوعًا من إسقاط الحزم لإدارة الاحتقان. يستخدم التنفيذ المرجعي استراتيجية WRED التي تأخذ في الاعتبار حجم الرسالة ومسافة السفر (راجع <a href="../../ar/docs/specs/tunnel-implementation/#tunnelthrottling">وثائق tunnel throttling</a> ). بسبب هذه الاستراتيجية، يكون المصدر الأساسي لفقدان الحزم هو OBEP.</p> <h2 id="التصميم">التصميم</h2> <p>عند إرسال رسالة، يختار المرسل أو يبني نفقًا مع OBEP يكون نفس جهاز التوجيه كإحدى IBGWs للمتلقي. عن طريق القيام بذلك، ستذهب الرسالة مباشرة من نفق إلى الآخر، دون الحاجة إلى إرسالها عبر الشبكة في المنتصف.</p>/ar/proposals/168-tunnel-bandwidth/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/168-tunnel-bandwidth/<h2 id="ملاحظة">ملاحظة</h2> <p>تمت الموافقة على هذا الاقتراح وهو الآن في <a href="../../ar/docs/specs/tunnel-implementation/#tunnel-creation-ecies">Tunnel Creation ECIES specification</a> اعتبارًا من API 0.9.65. لا توجد تطبيقات معروفة حتى الآن؛ تواريخ التنفيذ / نسخ API لم تتحدد بعد.</p> <h2 id="لمحة-عامة">لمحة عامة</h2> <p>مع زيادة أداء الشبكة خلال السنوات الأخيرة ببروتوكولات جديدة، وأنواع تشفير، وتحسينات في التحكم في الازدحام، أصبح بإمكان التطبيقات الأسرع مثل بث الفيديو أن تصبح ممكنة. تتطلب هذه التطبيقات عرض نطاق ترددي عالٍ عند كل خطوة في أنفاق عملاءهم.</p>/ar/proposals/156-ecies-routers/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/156-ecies-routers/<h2 id="ملاحظة">ملاحظة</h2> <p>نشر الشبكة والاختبار قيد التقدم. قابل للتعديل. الحالة:</p> <ul> <li>تم تنفيذ موجهات ECIES اعتبارًا من 0.9.48، راجع <a href="../../ar/docs/specs/common-structures/">Common</a> .</li> <li>تم تنفيذ بناء الأنفاق اعتبارًا من 0.9.48، راجع <a href="../../ar/docs/specs/tunnel-implementation/#tunnel-creation-ecies">Tunnel-Creation-ECIES</a> .</li> <li>تم تنفيذ الرسائل المشفرة للموجهات ECIES اعتبارًا من 0.9.49، راجع <a href="../../ar/docs/specs/ecies/">ECIES-ROUTERS</a> .</li> <li>تم تنفيذ رسائل بناء النفق الجديدة اعتبارًا من 0.9.51.</li> </ul> <h2 id="نظرة-عامة">نظرة عامة</h2> <h3 id="ملخص">ملخص</h3> <p>حاليًا تحتوي هويات الموجهات على مفتاح تشفير ElGamal. كانت هذه هي المعيار منذ بداية I2P. ElGamal بطيء ويحتاج إلى استبداله في جميع الأماكن التي يُستخدم فيها.</p>/ar/proposals/132-ports-range-in-routerinfo/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/132-ports-range-in-routerinfo/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>أو قائمة بدلاً من منفذ واحد.</p> <p>يمكن للعميل الاتصال بأي منها ويجب أن يختار عشوائيًا. سيجعل نمط الحركة أقل قابلية للتعرف، ويساعد في تجاوز DPI وبعض مرشحات مكافحة الـ DDoS.</p> <p>كما يمكن استخدامها لتوزيع الحمل على العقد ذات الأعباء العالية جدًا في المستقبل.</p> <h2 id="الدافع">الدافع</h2> <p>قيد التحديد</p> <h2 id="التصميم">التصميم</h2> <p>قيد التحديد</p> <h2 id="المواصفات">المواصفات</h2> <p>قيد التحديد</p> <h2 id="الهجرة">الهجرة</h2> <p>قيد التحديد</p>/ar/proposals/146-red25519/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/146-red25519/<h2 id="ملاحظة">ملاحظة</h2> <p>تنفيذ الشبكة والاختبار قيد التقدم. ممكن أن يخضع لتعديلات طفيفة. انظر إلى <a href="../../ar/docs/specs/red25519-signature-scheme/">specification</a> للحصول على المواصفات الرسمية.</p> <h2 id="نظرة-عامة">نظرة عامة</h2> <p>توضح هذه الاقتراح نظام توقيع قابل لإعادة التوزيع مناسب لإنشاء المقاصد التي يمكن تعميتها. يمكن أيضًا استخدامه لتعمية المقاصد الموجودة لنظام Ed25519، مع تقليل ضئيل في الفعالية.</p> <h2 id="الدافع">الدافع</h2> <p>يحدد <a href="../../ar/proposals/123-new-netdb-entries/">Proposal 123</a> تنسيق LeaseSet2 مشفرًا يجسد مبدأ السلطة الأقل: يُمنح كل مشارك في الشبكة فقط المعلومات الضرورية لدوره. على وجه الخصوص، فإن LeaseSet2 المشفر المنشور إلى Floodfill لا يكشف عن الوجهة الذي هو من أجلها، ولا يمكن عرض عقود الإيجار إلا من قبل شخص لديه معرفة مسبقة بالوجهة. ومع ذلك، لا تزال Floodfills بحاجة إلى أن تكون قادرة على التحقق من LeaseSet2 المشفرات عندما تكون منشورة، ويحتاج العملاء إلى ضمان إضافي بأن الوجهة هي التي فرضت المصادقة.</p>/ar/proposals/104-tls-transport/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/104-tls-transport/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>هذا الاقتراح يتناول تنفيذ نقل يستند إلى TLS.</p> <h2 id="الدافع">الدافع</h2> <p>إنها اقتراح متكرر بأن يكون لدينا نقل مقاوم للتجسس بحيث نكون مقاومين للبصمات والحظر من قبل مزودي خدمات الإنترنت والخصوم على المستوى الحكومي، مثل ما يمتلكه تور (أي محاولة الظهور كمثل جلسة HTTPS من Firefox) .</p> <h2 id="التصميم">التصميم</h2> <p>سيتم تحديده لاحقاً</p>/ar/proposals/134-gost/Mon, 01 Jan 0001 00:00:00 +0000/ar/proposals/134-gost/<h2 id="نظرة-عامة">نظرة عامة</h2> <p>يستخدم توقيع المنحنى الإهليلجي GOST R 34.10 من قبل المسؤولين والشركات في روسيا. قد يُبسط دعمه دمج التطبيقات القائمة (عادةً ما تكون مبنية على CryptoPro). دالة التجزئة هي GOST R 34.11 بقدر 32 أو 64 بايت. في الأساس يعمل بنفس الطريقة مثل EcDSA، حجم التوقيع والمفتاح العمومي هو 64 أو 128 بايت.</p> <h2 id="الدافع">الدافع</h2> <p>لم يتم الوثوق بتشفير المنحنى الإهليلجي بشكل كامل وقد ينتج الكثير من الشائعات حول الأبواب الخلفية المحتملة. لذلك لا يوجد نوع توقيع مطلق موثوق به من قبل الجميع. إضافة نوع توقيع واحد آخر سيعطي الناس خياراً أكبر لما يثقون به أكثر.</p>