الخلاصة

  • RFC 10032 وثيقة Informational في مسار IRTF وتعكس إجماع CFRG، وليست تكليفاً من مسار معايير IETF. تخصيصات IANA الستة أسماء ثابتة وليست التزاماً بالنشر.
  • يميز السجل بين AEGIS-128L وAEGIS-256 وأربعة أشكال متوازية X2/X4، لكنه لا يشفّر اختيار وسم 128 أو 256 بت. الأشكال المتوازية اختيارية ولا ينبغي اختيارها إلا باتفاق جميع الأطراف على المتغير المحدد.
  • يثبت الاختبار الذاتي للمكتبة تطابق تنفيذ بدائي مع متجهات ثابتة. ولا يثبت ما تفاوض عليه الطرفان، أو الملف التنفيذي ومسار المعالج المستخدمين، أو بناء nonce والبيانات المرتبطة، أو المجموعة التي حمت جلسة فعلية.
  • ينبغي لإيصال عهدة الخوارزمية أن يربط الوثيقة والسجل بملف البروتوكول والاختيار الموثّق والرمز وطول الوسم ودورات المفاتيح وnonce وترميز البيانات المرتبطة ومسار التشغيل والاختبارات والفشل والعدادات والتراجع والاستعادة.

السجل يمنع تضارب الأسماء فقط

خصصت IANA الرقم 32 لـAEAD_AEGIS128L والرقم 33 لـAEAD_AEGIS256، والرقمين 34 و35 لصيغتي AEGIS-128X2/X4، والرقمين 36 و37 لصيغتي AEGIS-256X2/X4. تتيح هذه القيم للمواصفات والإعدادات الإشارة إلى المتغير نفسه من دون أن تستخدم خوارزميات غير متوافقة معرّفاً عاماً واحداً.

لكن الرقم ليس سجلاً لجلسة. يوضح RFC 5116، الذي أنشأ واجهة AEAD وسجلها، أن تسجيل خوارزمية لا يعني اعتمادها أو التصديق على أمنها. كما أن الواجهة لا تقرر سياسة منع الإعادة أو التحكم في الوصول؛ فتلك مسؤولية البروتوكول المستدعي وتشغيله.

يحدد RFC 10032 الخوارزميات والمعلمات وإرشادات التشغيل ومتجهات الاختبار. لكنه لا يضع تفاوضاً واحداً لـTLS أو IPsec أو QUIC أو التخزين أو قناة خاصة. على كل ملف بروتوكول أن يحدد ما إذا كان سيعرض AEGIS، ومعنى كل معرّف، وطول الوسم، ومصدر المفتاح وnonce، والبايتات التي تصبح بيانات مرتبطة، وسلوك فشل المصادقة.

لذلك فعبارة «المكتبة تدعم AEGIS» تصف قدرة، أما عبارة «هذه الجلسة استخدمت AEGIS-256X2 بهذه المعلمات» فتصف اتفاقاً وتنفيذاً. لا ينقل رمز السجل الحقيقة من الأولى إلى الثانية.

مسار نشر الوثيقة جزء من معناها

نُشر RFC 10032 في سبتمبر 2026 ضمن مسار IRTF وبفئة Informational. وهو يمثل إجماع CFRG، لكنه ينص على أنه ليس منتجاً أو معياراً لـIETF، وأن نتائج IRTF قد لا تلائم النشر العملي.

هذا توصيف لطبيعة المراجعة والسلطة، وليس انتقاصاً من العمل. يشرح RFC 5743 إعداد مجموعة البحث ومراجعة IRSG وفحص IESG للتعارض مع أعمال التقييس. ويوضح RFC 7841 أن وثائق المسارات غير التابعة لـIETF لا تمر عادة بمراجعة واعتماد IETF الواسعين اللذين يخصان المعايير.

هناك أربع وقائع منفصلة: إجماع بحثي في CFRG، وموافقة IRSG على النشر، وفحص IESG للتعارض، وتخصيص IANA لمعرّفات فريدة. لا تثبت أي منها تبني بروتوكول، أو تمكين منتج افتراضياً، أو اختيار طرفين في اتصال.

في 20 سبتمبر كانت صفحة IANA العامة تعرض الصفوف الستة، بينما ظل عمود المرجع يشير إلى المسودة 18 وأظهرت الصفحة تاريخ تحديث في 7 يوليو. لا تجعل هذه الفجوة المرصودة الرموز باطلة؛ بل تبين لماذا يجب حفظ لقطة مؤرخة لكل من حالة النشر وحالة السجل.

الرمز لا يحمل طول وسم المصادقة

يستخدم AEGIS-128L مفتاحاً وnonce بطول 128 بت، ويستخدم AEGIS-256 كليهما بطول 256 بت. ويتيح الاثنان وسم مصادقة بطول 128 أو 256 بت. تحمل أسماء IANA العائلة ودرجة التوازي عند وجودها، ولا تحمل طول الوسم.

يغير هذا الاختيار الادعاء الأمني وتنسيق السلك. يصف RFC 10032 جهداً يقارب 2^64 لخاصية الالتزام مع وسم 128 بت، ونحو 2^128 مع وسم 256 بت، ضمن الحالة المحددة في الوثيقة. قد يتفق طرفان على الرمز 32 بينما ينتظر أحدهما 16 بايت للوسم والآخر 32 بايت؛ يتطابق السجل ولا يتطابق الاتصال.

يجب أيضاً تثبيت التأطير: يمكن إبقاء النص المشفر والوسم منفصلين أو إلحاق الوسم مباشرة بالنص المشفر. لا تخبر عبارة «AEGIS-128L» المراجع بعدد البتات المقروءة أو موضع الحد.

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

السرعة المتوازية قرار توافق أيضاً

صُمم AEGIS-128X وAEGIS-256X للاستفادة من سجلات متجهية عريضة وتعليمات AES متجهية، وتشير X2 وX4 إلى درجتي توازٍ اثنتين وأربع. تختلف الفائدة باختلاف المعمارية والتنفيذ.

يضع RFC 10032 قيداً واضحاً: لا ينبغي للبروتوكول اختيار شكل متوازٍ إلا عندما تتفق الأطراف كلها على المتغير المحدد. ينبغي أن يبقى AEGIS-128L وAEGIS-256 خيارين افتراضيين، ويجوز للتنفيذ إغفال الأشكال المتوازية.

لذلك لا ينشئ قياس أداء جذاب لـX4 مجموعة محمولة. قد لا يملك الطرف الآخر إلا الشكل الأساسي، أو قد يُبنى الملف التنفيذي بلا مسار X، أو تتغير تعليمات المعالج المرئية بعد نقل آلة افتراضية، أو يعود موزع التشغيل لمسار آخر بينما يظل الإعداد يقول «AEGIS».

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

اتساع nonce لا يلغي العهدة

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

تسمح عائلة 128 بت حتى 2^48 رسالة لكل مفتاح عند استخدام nonce عشوائي واحتمال التصادم المذكور، نحو 2^-33. وتصف الوثيقة nonce العشوائي لعائلة 256 بت بأنه بلا حد عملي. لا يعني ذلك سقوط قاعدة التفرد أو عدم الحاجة إلى تصميم محلي للتوليد والمحاسبة.

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

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

متجه الاختبار لا يصل إلى الجلسة الحية

يوفر RFC 10032 متجهات كثيرة لجولة AES والخوارزميات الأساسية وX2/X4 وأشكال MAC. تكشف أخطاء ترتيب البايتات والإنهاء والكتلة الجزئية وتوليد الوسم. وتضيف المقارنة بين تطبيقات مستقلة قيمة أخرى.

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

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

إيصال عهدة من أربعة عشر جزءاً

الإيصال التالي رقابة تشغيلية تحريرية يقترحها Daniel Kade، وليس حقلاً في RFC 10032 ولا شهادة امتثال من IETF أو IRTF أو CFRG أو IANA.

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

رابعاً: الرمز الرقمي والمتغير الأساسي أو X2 أو X4. خامساً: طول الوسم وتأطير النص والوسم. سادساً: قدرة الطرفين وسلوك غياب الدعم. سابعاً: مصدر المفتاح واشتقاقه وسياقه وعصره ومعرّفه وحد محوه.

ثامناً: بناء nonce واستمراره ونطاق تفرده وإعادة التشغيل والعداد لكل مفتاح. تاسعاً: حقول البيانات المرتبطة وترميزها المعياري. عاشراً: بناء المكتبة ومسار CPU/المتجه والتراجع. حادي عشر: المتجهات الإيجابية والمقارنة بين التطبيقات والحالات السلبية.

ثاني عشر: دلالة الفشل ومنع النص الواضح ودليل الزمن الثابت والتنبيه. ثالث عشر: الربط بجلسات أو حزم محددة وقياس الاستخدام. رابع عشر: قواعد البديل ورفض التخفيض ومحفزات الاستعادة والخروج من مجموعة التوافق ومدة حفظ الدليل.

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

المصادر