الخلاصة

  • يبدأ الترتيب المعتاد في RFC 1991 بتوقيع البيانات الحرفية، ثم ضغط التوقيع والبيانات معاً، وتشفير الناتج بمفتاح جلسة، ووضع حزمة مفتاح مشفّرة لكل مستلم، ثم إضافة ASCII Armor عند الحاجة.
  • يحدد CTB ونطاقات الطول بنية الملف، بينما يكشف CRC وفحص المفتاح أنواعاً ضيقة من الخطأ. لا يثبت أي منها بمفرده المرسل أو التفويض أو التسليم.
  • يغطي توقيع المستند بايتات محددة، لا كل البيانات الوصفية الظاهرة. اسم الملف والوقت الموثوق وربط المفتاح بشخص والسلطة المؤسسية تحتاج إلى أدلة منفصلة.

لا توجد «نجاح واحد» داخل الرسالة

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

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

توضح حزمة البيانات الحرفية الحد بدقة. فهي تحتوي على نمط واسم ملف مقترح ووقت وبيانات. لكن توقيع المستند يحسب الملخص على حقل البيانات الحرفية وحده. قد تعرض الواجهة الاسم والوقت إلى جانب علامة «توقيع صحيح»، إلا أن التجاور البصري لا يجعلهما موقعين.

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

CTB يصف الطريق داخل الملف

تبدأ بنية الحزمة بما سماه المستند Cipher Type Byte أو CTB. تحدد بتاته نوع الحزمة وطريقة قراءة طولها، فيعرف المحلل أين توجد حزمة توقيع أو ضغط أو تشفير أو بيانات حرفية، وأين تنتهي. وهناك صيغة بلا طول صريح للبيانات المضغوطة تمتد حتى نهاية البنية الحاوية.

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

وتكشف صيغة الطول غير المحدد اعتماداً مهماً: لا معنى لعبارة «حتى النهاية» ما لم يكن حد البنية الحاوية معروفاً. قد يكون التحليل المحلي سليماً بينما تكون فرضية النظام عن الجسم الكامل خاطئة.

ASCII Armor حل مشكلة نقل

لم تكن مسارات البريد في تلك المرحلة تحافظ دائماً على البيانات الثنائية. لذلك حوّل ASCII Armor كل ثلاثة بايتات إلى أربعة محارف قابلة للطباعة، وأضاف رأساً وحقولاً اختيارية وجسماً وفحص CRC من 24 بتاً وذيلًا. يُحسب CRC على البيانات الثنائية قبل تحويل radix-64.

يبدو شكل الكتلة كختم، لكن RFC 1991 يقول إن رؤوس الغلاف تخص الغلاف لا الرسالة، وقد تتغير أثناء النقل، ولذلك ينبغي ألا تحمل معلومات مهمة. إذا ظهر مفتاح رأس غير معروف لكنه منسق بصورة صحيحة، يُبلّغ عنه ثم تستمر المعالجة.

إذن يثبت تطابق CRC حقيقة ضيقة: أن النص القابل للطباعة أعاد بناء تدفق ثنائي متوافق مع فحص الأخطاء. لا يصادق على المرسل؛ يستطيع مهاجم استبدال الكتلة كلها وحساب CRC جديد. ولا يثبت أن الجسم الداخلي يحوي توقيعاً صحيحاً.

العثور على المفتاح لا يساوي إثبات الهوية

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

ومعرّف المفتاح البالغ 64 بت أداة لاختيار المرشحين فقط. ينبه RFC إلى إمكان اشتراك مفتاحين فيه بالمصادفة أو بالقصد. لذلك يحتاج المسار الإثباتي إلى مادة المفتاح الفعلية، وقائمة المرشحين، وطريقة الحل، وحالة الإلغاء أو الاختراق، وسياسة الثقة والتفويض.

حتى وقت التوقيع العادي يظل ادعاءً. يذكر المستند أنه يكون عادة قريباً من الإنشاء، من دون إلزام، ويمكن للمستخدم اختياره. يتطلب الوقت الموثوق توقيع موثق مستقل على حزمة التوقيع. صحة الحساب لا تعني الحداثة أو الزمن القانوني.

قيمة تاريخية في ضيق الاختصاص

تسجل صفحة RFC Editor الوثيقة بوصفها Informational صدرت في أغسطس 1996 ثم أصبحت obsolete بواسطة RFC 4880. وتحفظ نسخ النص وHTML وسجل IETF ما حددته الوثيقة، لا دليلاً على أن كل تطبيق تاريخي نفذه كاملاً.

يوفر إدخال IETF في الدليل تنقلاً مؤسسياً فقط؛ ولا يثبت أن المنظمة تؤيد تفسير هذا المقال.

تُستخدم هنا مقالات Lu Heng عن أولوية الشفرة العاملة والحد الأدنى للمواصفة والقرار المحلي وطبقات الواقع كمنهج تحريري، لا كمصدر تاريخي عن PGP. الفكرة المفيدة هي ألا تستعير نتيجة تقنية سلطة من حقيقة لم ترصدها.

لم يكن نجاح RFC 1991 وعداً بدليل شامل. كان طريقة لجعل التحويلات قابلة للفصل وإعادة الفحص. تبقى السلسلة قوية حين يحافظ كل إيصال على حدوده.