مُهمل، لم يعد مدعوماً. معطل افتراضياً اعتباراً من 0.9.40 2019-05. تمت إزالة الدعم اعتباراً من 0.9.50 2021-05. تم استبداله بـ NTCP2 . NTCP هو نقل مبني على Java NIO تم تقديمه في إصدار I2P 0.6.1.22. Java NIO (new I/O) لا يعاني من مشاكل خيط واحد لكل اتصال الخاصة بنقل TCP القديم. NTCP-over-IPv6 مدعوم اعتباراً من الإصدار 0.9.8.
بشكل افتراضي، يستخدم NTCP عنوان IP/المنفذ المكتشف تلقائياً بواسطة SSU. عند التمكين في config.jsp، سيقوم SSU بإشعار/إعادة تشغيل NTCP عند تغيير العنوان الخارجي أو عند تغيير حالة جدار الحماية. يمكنك الآن تمكين TCP الوارد دون الحاجة لعنوان IP ثابت أو خدمة dyndns.
كود NTCP داخل I2P خفيف نسبياً (ربع حجم كود SSU) لأنه يستخدم طبقة نقل Java TCP الأساسية للتسليم الموثوق.
مواصفات عنوان الـ Router
يتم تخزين الخصائص التالية في قاعدة بيانات الشبكة.
- اسم النقل: NTCP
- host: IP (IPv4 أو IPv6). عنوان IPv6 المختصر (مع “::”) مسموح. أسماء المضيفين كانت مسموحة سابقاً، لكنها مهجورة اعتباراً من الإصدار 0.9.32. انظر اقتراح 141.
- port: 1024 - 65535
مواصفات بروتوكول NTCP
تنسيق الرسالة القياسي
بعد الإنشاء، ينقل بروتوكول NTCP رسائل I2NP فردية، مع checksum بسيط. يتم ترميز الرسالة غير المشفرة كما يلي:
+-------+-------+-------+-------+-------+-------+-------+-------+
| sizeof(data) | |
+-------+-------+ +
| data |
~ ~
| |
+ +-------+-------+-------+
| | padding
+-------+-------+-------+-------+-------+-------+-------+-------+
| Adler checksum of sz+data+pad |
+-------+-------+-------+-------+-------+-------+-------+-------+
يتم بعد ذلك تشفير البيانات باستخدام AES/256/CBC. يتم التفاوض على مفتاح الجلسة للتشفير أثناء الإنشاء (باستخدام Diffie-Hellman 2048 bit). يتم تنفيذ الإنشاء بين router إثنين في فئة EstablishState ومفصل أدناه. إن IV لتشفير AES/256/CBC هو البايتات الـ16 الأخيرة من الرسالة المشفرة السابقة.
مطلوب من 0-15 بايت من الحشو لجعل الطول الإجمالي للرسالة (بما في ذلك الستة بايتات للحجم والمجموع الاختباري) مضاعفاً للعدد 16. الحد الأقصى لحجم الرسالة حالياً هو 16 كيلوبايت. لذلك الحد الأقصى لحجم البيانات حالياً هو 16 كيلوبايت - 6، أو 16378 بايت. الحد الأدنى لحجم البيانات هو 1.
تنسيق رسالة مزامنة الوقت
حالة خاصة واحدة هي رسالة البيانات الوصفية حيث يكون sizeof(data) هو 0. في تلك الحالة، يتم تشفير الرسالة غير المشفرة كما يلي:
+-------+-------+-------+-------+-------+-------+-------+-------+
| 0 | timestamp in seconds | uninterpreted
+-------+-------+-------+-------+-------+-------+-------+-------+
uninterpreted | Adler checksum of bytes 0-11 |
+-------+-------+-------+-------+-------+-------+-------+-------+
الطول الإجمالي: 16 بايت. يتم إرسال رسالة مزامنة الوقت على فترات تبلغ حوالي 15 دقيقة. يتم تشفير الرسالة تماماً كما يتم تشفير الرسائل العادية.
المجاميع الاختبارية
تستخدم الرسائل القياسية ورسائل مزامنة الوقت مجموع التحقق Adler-32 كما هو محدد في مواصفة ZLIB .
مهلة انتهاء الخمول
مهلة الخمول وإغلاق الاتصال يكون حسب تقدير كل نقطة نهاية وقد يختلف. التطبيق الحالي يقلل المهلة الزمنية عندما يقترب عدد الاتصالات من الحد الأقصى المُكوَّن، ويزيد المهلة الزمنية عندما يكون عدد الاتصالات منخفض. الحد الأدنى الموصى به للمهلة الزمنية هو دقيقتان أو أكثر، والحد الأقصى الموصى به للمهلة الزمنية هو عشر دقائق أو أكثر.
تبادل معلومات الـ Router
بعد التأسيس، وكل 30-60 دقيقة بعد ذلك، يجب على الـ router-ين عموماً تبادل RouterInfos باستخدام DatabaseStoreMessage. ومع ذلك، يجب على Alice التحقق مما إذا كانت الرسالة الأولى في الطابور هي DatabaseStoreMessage حتى لا ترسل رسالة مكررة؛ وهذا غالباً ما يحدث عند الاتصال بـ floodfill router.
تسلسل الإنشاء
في حالة التأسيس، يوجد تسلسل رسائل من 4 مراحل لتبادل مفاتيح DH والتوقيعات. في أول رسالتين يتم تبادل Diffie Hellman بحجم 2048 بت. ثم يتم تبادل توقيعات البيانات الحرجة لتأكيد الاتصال.
Alice contacts Bob
=========================================================
X+(H(X) xor Bob.identHash)----------------------------->
<----------------------------------------Y+E(H(X+Y)+tsB+padding, sk, Y[239:255])
E(sz+Alice.identity+tsA+padding+S(X+Y+Bob.identHash+tsA+tsB), sk, hX_xor_Bob.identHash[16:31])--->
<----------------------E(S(X+Y+Alice.identHash+tsA+tsB)+padding, sk, prev)
Legend:
X, Y: 256 byte DH public keys
H(): 32 byte SHA256 Hash
E(data, session key, IV): AES256 Encrypt
S(): Signature
tsA, tsB: timestamps (4 bytes, seconds since epoch)
sk: 32 byte Session key
sz: 2 byte size of Alice identity to follow
تبادل مفاتيح DH
تبادل مفاتيح DH الأولي بحجم 2048 بت يستخدم نفس العدد الأولي المشترك (p) والمولد (g) المستخدم في تشفير ElGamal الخاص بـ I2P.
يتكون تبادل مفاتيح DH من عدد من الخطوات، الموضحة أدناه. التطابق بين هذه الخطوات والرسائل المرسلة بين routers I2P، مُحدد بالخط العريض.
- تُولد أليس عدداً صحيحاً سرياً x. ثم تحسب
X = g^x mod p. - ترسل أليس X إلى بوب (الرسالة 1).
- يُولد بوب عدداً صحيحاً سرياً y. ثم يحسب
Y = g^y mod p. - يرسل بوب Y إلى أليس. (الرسالة 2)
- يمكن لأليس الآن حساب
sessionKey = Y^x mod p. - يمكن لبوب الآن حساب
sessionKey = X^y mod p. - لدى كل من أليس وبوب الآن مفتاح مشترك
sessionKey = g^(x*y) mod p.
يتم استخدام sessionKey بعد ذلك لتبادل الهويات في الرسالة 3 و الرسالة 4. طول الأس (x و y) لتبادل DH موثق في صفحة التشفير .
تفاصيل مفتاح الجلسة
يتم إنشاء مفتاح الجلسة المكون من 32 بايت كما يلي:
- خذ مفتاح DH المتبادل، ممثلاً كمصفوفة بايت BigInteger موجبة بأقل طول (تكامل الاثنين big-endian)
- إذا كانت البت الأكثر أهمية هي 1 (أي array[0] & 0x80 != 0)، أضف بايت 0x00 في المقدمة، كما في تمثيل Java’s BigInteger.toByteArray()
- إذا كانت مصفوفة البايت هذه أكبر من أو تساوي 32 بايت، استخدم أول (الأكثر أهمية) 32 بايت
- إذا كانت مصفوفة البايت هذه أقل من 32 بايت، أضف بايتات 0x00 للتمديد إلى 32 بايت. (احتمال ضئيل جداً)
الرسالة 1 (طلب الجلسة)
هذا هو طلب DH. أليس لديها بالفعل Router Identity الخاص ببوب، وعنوان IP، والمنفذ، كما هو موجود في Router Info الخاص به، والذي تم نشره إلى network database . أليس ترسل إلى بوب:
X+(H(X) xor Bob.identHash)----------------------------->
Size: 288 bytes
المحتويات:
+----+----+----+----+----+----+----+----+
| X, as calculated from DH |
+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| HXxorHI |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
X :: 256 byte X from Diffie Hellman
HXxorHI :: SHA256 Hash(X) xored with SHA256 Hash(Bob's RouterIdentity)
(32 bytes)
ملاحظات:
- يتحقق Bob من HXxorHI باستخدام router hash الخاص به. إذا لم يتم التحقق بنجاح، فإن Alice قد اتصلت بـ router خاطئ، ويقوم Bob بقطع الاتصال.
الرسالة 2 (تم إنشاء الجلسة)
هذا هو رد DH. يرسل بوب إلى أليس:
<----------------------------------------Y+E(H(X+Y)+tsB+padding, sk, Y[239:255])
Size: 304 bytes
المحتويات غير المشفرة:
+----+----+----+----+----+----+----+----+
| Y as calculated from DH |
+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| HXY |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| tsB | padding |
+----+----+----+----+ +
| |
+----+----+----+----+----+----+----+----+
Y :: 256 byte Y from Diffie Hellman
HXY :: SHA256 Hash(X concatenated with Y)
(32 bytes)
tsB :: 4 byte timestamp (seconds since the epoch)
padding :: 12 bytes random data
المحتويات المشفرة:
+----+----+----+----+----+----+----+----+
| Y as calculated from DH |
+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| encrypted data |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
Y: 256 byte Y from Diffie Hellman
encrypted data: 48 bytes AES encrypted using the DH session key and
the last 16 bytes of Y as the IV
ملاحظات:
- قد تقطع Alice الاتصال إذا كان انحراف الساعة مع Bob مرتفعًا جداً كما هو محسوب باستخدام tsB.
الرسالة 3 (تأكيد الجلسة أ)
يحتوي هذا على هوية router الخاص بأليس، وتوقيع البيانات الحرجة. ترسل أليس إلى بوب:
E(sz+Alice.identity+tsA+padding+S(X+Y+Bob.identHash+tsA+tsB), sk, hX_xor_Bob.identHash[16:31])--->
Size: 448 bytes (typ. for 387 byte identity and DSA signature), see notes below
المحتويات غير المشفرة:
+----+----+----+----+----+----+----+----+
| sz | Alice's Router Identity |
+----+----+ +
| |
~ . . . ~
| |
+ +----+----+----+
| | tsA
+----+----+----+----+----+----+----+----+
| padding |
+----+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| signature |
+ +
| |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
sz :: 2 byte size of Alice's router identity to follow (387+)
ident :: Alice's 387+ byte RouterIdentity
tsA :: 4 byte timestamp (seconds since the epoch)
padding :: 0-15 bytes random data
signature :: the Signature of the following concatenated data:
X, Y, Bob's RouterIdentity, tsA, tsB.
Alice signs it with the SigningPrivateKey associated with
the SigningPublicKey in her RouterIdentity
المحتويات المشفرة:
+----+----+----+----+----+----+----+----+
| |
+ +
| encrypted data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
encrypted data: 448 bytes AES encrypted using the DH session key and
the last 16 bytes of HXxorHI (i.e., the last 16 bytes
of message #1) as the IV
448 is the typical length, but it could be longer, see below.
ملاحظات:
- يتحقق Bob من التوقيع، وفي حالة الفشل، يقطع الاتصال.
- قد يقطع Bob الاتصال إذا كان انحراف الساعة مع Alice مرتفعًا جدًا كما هو محسوب باستخدام tsA.
- ستستخدم Alice آخر 16 بايت من المحتويات المشفرة لهذه الرسالة كـ IV للرسالة التالية.
- حتى الإصدار 0.9.15، كانت هوية router دائمًا 387 بايت، والتوقيع كان دائمًا توقيع DSA بحجم 40 بايت، والحشو كان دائمًا 15 بايت. اعتبارًا من الإصدار 0.9.16، قد تكون هوية router أطول من 387 بايت، ونوع التوقيع وطوله مستنتجان من نوع Signing Public Key في Router Identity الخاصة بـ Alice. الحشو حسب الحاجة لمضاعف 16 بايت للمحتويات الكاملة غير المشفرة.
- لا يمكن تحديد الطول الإجمالي للرسالة دون فك تشفيرها جزئيًا لقراءة Router Identity. نظرًا لأن الحد الأدنى لطول Router Identity هو 387 بايت، والحد الأدنى لطول Signature هو 40 (لـ DSA)، فإن الحد الأدنى لحجم الرسالة الإجمالي هو 2 + 387 + 4 + (طول التوقيع) + (حشو إلى 16 بايت)، أو 2 + 387 + 4 + 40 + 15 = 448 لـ DSA. يمكن للمستقبل قراءة هذا المقدار الأدنى قبل فك التشفير لتحديد طول Router Identity الفعلي. بالنسبة للشهادات الصغيرة في Router Identity، سيكون ذلك على الأرجح الرسالة بأكملها، ولن تكون هناك بايتات إضافية في الرسالة تتطلب عملية فك تشفير إضافية.
الرسالة 4 (تأكيد الجلسة B)
هذا هو توقيع البيانات الحرجة. يرسل بوب إلى أليس:
<----------------------E(S(X+Y+Alice.identHash+tsA+tsB)+padding, sk, prev)
Size: 48 bytes (typ. for DSA signature), see notes below
المحتويات غير المشفرة:
+----+----+----+----+----+----+----+----+
| |
+ +
| signature |
+ +
| |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| padding |
+----+----+----+----+----+----+----+----+
signature :: the Signature of the following concatenated data:
X, Y, Alice's RouterIdentity, tsA, tsB.
Bob signs it with the SigningPrivateKey associated with
the SigningPublicKey in his RouterIdentity
padding :: 0-15 bytes random data
المحتويات المشفرة:
+----+----+----+----+----+----+----+----+
| |
+ +
| encrypted data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
encrypted data: Data AES encrypted using the DH session key and
the last 16 bytes of the encrypted contents of message #2 as the IV
48 bytes for a DSA signature, may vary for other signature types
ملاحظات:
- تتحقق Alice من التوقيع، وفي حالة الفشل، تسقط الاتصال.
- سيستخدم Bob آخر 16 بايت من المحتويات المشفرة لهذه الرسالة كـ IV للرسالة التالية.
- خلال الإصدار 0.9.15، كان التوقيع دائماً توقيع DSA بحجم 40 بايت وكانت الحشوة دائماً 8 بايت. اعتباراً من الإصدار 0.9.16، نوع التوقيع وطوله مضمنان حسب نوع Signing Public Key في Router Identity الخاص بـ Bob. الحشوة حسب الضرورة لمضاعف من 16 بايت لكامل المحتويات غير المشفرة.
بعد التأسيس
يتم إنشاء الاتصال، وقد يتم تبادل الرسائل القياسية أو رسائل مزامنة الوقت. جميع الرسائل اللاحقة مشفرة باستخدام AES باستخدام مفتاح جلسة DH المتفاوض عليه. ستستخدم Alice آخر 16 بايت من المحتويات المشفرة للرسالة رقم 3 كـ IV التالي. سيستخدم Bob آخر 16 بايت من المحتويات المشفرة للرسالة رقم 4 كـ IV التالي.
رسالة فحص الاتصال
بدلاً من ذلك، عندما يتلقى Bob اتصالاً، يمكن أن يكون اتصال فحص (ربما بناءً على طلب Bob من شخص ما للتحقق من المستمع الخاص به). Check Connection غير مستخدم حالياً. ومع ذلك، للتسجيل، يتم تنسيق اتصالات الفحص كما يلي. سيتلقى اتصال معلومات الفحص 256 بايت يحتوي على:
- 32 بايت من البيانات غير المفسرة والمتجاهلة
- 1 بايت للحجم
- عدد البايتات المكونة لعنوان IP الخاص بال router المحلي (كما يصل إليه الطرف البعيد)
- رقم منفذ من 2 بايت تم الوصول إلى ال router المحلي من خلاله
- وقت شبكة i2p من 4 بايت كما هو معروف للطرف البعيد (ثوانٍ منذ العصر المرجعي)
- بيانات حشو غير مفسرة، حتى البايت 223
- xor لهاش هوية ال router المحلي و SHA256 للبايتات من 32 حتى البايت 223
تم تعطيل فحص الاتصال بالكامل اعتباراً من الإصدار 0.9.12.
النقاش
الآن على صفحة مناقشة NTCP .
العمل المستقبلي
يجب زيادة الحد الأقصى لحجم الرسالة إلى حوالي 32 كيلوبايت.
قد تكون مجموعة من أحجام الحزم الثابتة مناسبة لإخفاء تجزئة البيانات بشكل إضافي عن الخصوم الخارجيين، ولكن حشو tunnel و garlic والحشو من طرف إلى طرف يجب أن يكون كافياً لمعظم الاحتياجات حتى ذلك الوقت. ومع ذلك، لا يوجد حالياً أي نص على الحشو ما وراء حدود الـ 16 بايت التالية، لإنشاء عدد محدود من أحجام الرسائل.
يجب مقارنة استخدام الذاكرة (بما في ذلك ذاكرة النواة) لـ NTCP مع استخدام الذاكرة لـ SSU.
هل يمكن حشو رسائل التأسيس بشكل عشوائي بطريقة ما، لإحباط تحديد حركة مرور I2P بناءً على أحجام الحزم الأولية؟