الخلاصة

  • جعل RFC 1969 آخر كتلة مشفّرة في رزمة PPP مدخلاً أولياً لـCBC في الرزمة التالية؛ وفر قيمة تهيئة جديدة لكل رزمة، لكنه ربط فكها بترتيب سابق خارجها.
  • انتقل nonce أولي من 64 بت علناً ثم شُفّر بالمفتاح المشترك لـDES لبدء السلسلة. وكشف رقم تسلسل صريح من 16 بت الفجوة، لكنه لم يوثّق المحتوى أو الطرف.
  • إذا فُقدت N-1 تعذر فك N. وإذا وصل نص N المشفّر أمكن استعمال كتلته الأخيرة لفك N+1؛ عادت الحالة ولم يعد النصان المفقودان.

رزمة لا تُقرأ ولا يجوز إهمالها

يفترض مثال RFC 1969 أن N-1 ضاعت بينما وصلت N وN+1. يحتاج النص الواضح لـN إلى آخر كتلة مشفّرة من N-1، وهي غير موجودة. أما N+1 فتحتاج إلى آخر كتلة من N، وهذه حاضرة في النص المشفّر حتى لو بقي محتوى N مجهولاً.

لذلك لا ينبغي أن يرمي المستقبل N لمجرد فشل فكها. فمحتواها غير متاح، لكن ذيلها يحمل موضع السلسلة. تمتد خسارة واحدة إلى نصين واضحين، ثم يعود الحساب في الرزمة الثالثة.

كلمة الاستعادة تخص حالة CBC فقط. لا يعيد البروتوكول بناء N-1 أو N، ولا يصف إعادة إرسال، ولا يثبت أن PPP أو التطبيق تسلّم نتيجة. استئناف القدرة الحسابية ليس استرجاعاً للبيانات.

لماذا تجاوزت الذاكرة حدود الرزمة

نُشر RFC 1969 في يونيو 1996 بصفة Informational ليحدد DES-CBC كبروتوكول بيانات داخل PPP ECP. بعد وصول ECP إلى Opened، كان المرسل يشفّر حقلي Protocol وInformation بمفتاح 56 بت، مع استثناء رزم LCP وECP.

بعد الرزمة الأولى تصبح C[0] هي آخر كتلة مشفّرة في الرزمة السابقة. لا يلزم حمل متجه جديد في كل datagram، ولا يبدأ النص المتكرر دائماً من الحالة نفسها. لكن الرزمة المنفردة لم تعد تحتوي كل ما يلزم لفكها.

ظل حد PPP مرئياً للنقل ولم يعد حدّاً للحالة. من هنا جاءت الحاجة إلى ترتيب صريح. أما تاريخ تفاوض ECP العام فموضعه RFC 1968؛ يبدأ هذا التحليل بعد اختيار DESE.

nonce معلن والمفتاح خارج النص

احتوى خيار DESE، بطول عشرة octets، على Initial Nonce من ثمانية. يقدمه المستقبل للرزمة الأولى التي يرسلها peer نحوه. أوصى RFC بقيمة جديدة في كل تفاوض وضرب مثلاً زمنياً يجمع الثواني والنانوثواني.

كان nonce يمر علناً. القيمة الابتدائية الفعلية هي E[k](nonce) تحت مفتاح DES المشترك. يمنح nonce اختلاف البداية، ويمنح المفتاح السرية، ويمنح النص المشفّر السابق الاستمرار. لا يصير العنصر العلني اعتماداً سرياً.

ترك RFC طريقة توزيع المفتاح خارج نطاقه، وذكر الإعداد اليدوي وإمكان استخدام PPP authentication أو Multilink Endpoint Identifier في اختيار السر. يثبت نجاح الفك وجود مفتاح وحالة متوافقين، لا هوية مؤسسة أو مستخدم بعينه.

رقم يحدد موضعاً لا أصالة

بدأ Sequence Number من 16 بت بالصفر بعد Opened. تكشف القفزة أن الذيل المخزن قد لا يكون سلف الرزمة الحاضرة.

لم يتحقق الرقم من البتات، ولم يعرّف RFC 1969 له MAC مستقلاً. قد تنتج الفجوة من فقد أو إعادة ترتيب أو إسقاط محلي أو تدخل نشط، ولا يحدد الرقم المرسل.

قال RFC 2419 لاحقاً بوضوح إن الهدف confidentiality وحدها، لا integrity أو authentication أو nonrepudiation، ولا ضمان ضد replay أو cut-and-paste أو active tampering. النص القابل للفك ليس دليلاً آلياً على عدم تغييره.

ثمانية octets تظهر في حساب MRU

يعمل DES في كتل من ثمانية. سمح RFC 1969 بذيل عشوائي للبروتوكولات ذات الطول الداخلي مثل IP وIPX وXNS وCLNP، واستعمل self-describing padding حين تغيّر البايتات الزائدة المعنى. وهكذا اعتمد الحد على تصنيف البروتوكول الداخلي.

جاء أسلوب الحشو الذاتي من RFC 1570. وقد يحتاج نص مصطفّ أصلاً إلى ثمانية octets أخرى إذا بدت نهايته كحشو. وفي مثال MRU، مع PFC وMRU أصلي من مضاعفات ثمانية، يتطلب Protocol field من octet واحد سبعة للحشو؛ ويضاف اثنان للتسلسل وتأثير الغلاف، فيكبر Information field الخاص بـDESE عشرة octets. تفاوض DESE لا يزيد MRU تلقائياً لأن خيارات PPP مستقلة.

لماذا أخذ DESE-bis رقماً جديداً

تسجل صفحة RFC 2419 أنه أبطل RFC 1969. فرض DESE-bis حشواً ذاتي الوصف على كل النصوص، مستقلاً عن خيار PPP SDP، وثبت الحد الأقصى بثمانية، وطلب إسقاط الإطار إذا لم يطابق الحشو النمط.

ولأن المستقبل القديم والجديد قد يفسران الناتج نفسه على نحو مختلف، أخذ DESE-bis ECP Type 3. أُلغي Type 1 القديم ويجب رفضه. يحفظ سجل IANA لـPPP Type 1 بوصفه Deprecated وType 3 لـDESE-bis.

لم يستبدل RFC 2419 DES بـTriple-DES. حدد RFC 2420 بروتوكول 3DESE منفصلاً تحت Type 2. كان التغيير توحيداً للحشو والتفسير، ومنعاً لمزج النسخ بصمت، وانتقالاً إلى Standards Track، وشرحاً أدق لحدود الأمن.

أثر قانوني داخل سجل تقني

ذكر RFC 1969 وجود شفرة DES-ECB في مرجع، ثم قال إن قوانين التصدير الأمريكية تمنع إدراج شفرة جاهزة للترجمة. بقيت العبارة في RFC 2419. إنها دليل مباشر على أن قيود تصدير التعمية في التسعينيات أثرت في محتوى الوثيقة.

لا تثبت العبارة قانونية منتج، أو أصل تنفيذ، أو تصديره وانتشاره. غياب الشفرة من RFC لا يعني غياب البرنامج ولا يقدم حكماً أمنياً.

يثبت IETF Datatracker وRFC Editor الهوية والتعاقب. لم تُرجع صفحة errata نصاً قابلاً للاستخدام عند الحفظ، لذلك لا ندعي أن سجل التصحيحات فارغ.

إيصالات منفصلة لكل طبقة

ينبغي فصل اتجاه ECP وType، وبصمة nonce ومرجع المفتاح، ورقم التسلسل، والذيل المستخدم، ونتيجة الفك، والتحقق من الحشو، وقرار PPP وفق RFC 1661. تسليم التطبيق إيصال لاحق.

يقدم Heng Lu في Running-Code Primacy منهج وصل النص بالتشغيل الملحوظ قبل توسيع الادعاء. يحصر Minimum Initial Specification سلطة الحقل في وظيفته الدنيا. ويمنع Reality Layers وReality, Not Advocacy تحويل الرمز إلى نتيجة أو اختراع الدوافع. هذه عدسة تحريرية لا مصدراً لتاريخ DESE.