الخلاصة
- يحدد RFC 10032 استخدام AEGIS كتعمية موثقة، ومولّد تدفق، ورمز توثيق رسالة. في التعمية يجب ألا يتكرر زوج
(المفتاح، nonce)ويجب حبس النص حتى نجاح التحقق؛ أما التدفق فيتخلص من الوسم عمداً؛ ودالة MAC وحدها تسمح بإعادة استخدام الزوج مع مدخلات مختلفة. - رقم IANA أو نجاح متجه اختبار أو نتيجة أداء لا يثبت الدور الذي استدعاه التطبيق. الدليل الحاسم يسجل غرض المفتاح، ونطاق nonce، وترميز البيانات المرتبطة، ومسار التنفيذ، والحد الذي منع البايتات غير المتحققة من إحداث أثر.
نُشر RFC 10032 في سبتمبر 2026 بصفة Informational ضمن مسار IRTF، وهو يسجل توافق CFRG ولا يمثل معياراً في مسار معايير IETF. يصف AEGIS-128L وAEGIS-256، إضافة إلى AEGIS-128X وAEGIS-256X المهيأتين للمعالجات ذات السجلات المتجهية الكبيرة وتعليمات AES المتجهية. تشترك كلها في دالة جولة AES.
خصصت IANA الأرقام من 32 إلى 37 لصيغ الأساس وX2 وX4. هذه الأرقام تنسق الأسماء، لكنها لا تختار ما إذا كان الاستدعاء AEAD أو تدفقاً أو MAC، ولا تحدد طول الوسم، أو بنية البيانات المرتبطة، أو سياسة nonce، أو سلوك الفشل.
يمتلك مقال BTW السابق عن RFC 10032 حدّ «رقم الخوارزمية ليس إيصال تفاوض». يبدأ هذا التحقيق بعد ذلك الحد: بعد اختيار العائلة، أي وظيفة نُفذت فعلاً، وما الذي يحق لمخرجها أن يثبته؟
التعمية الموثقة تضع بوابة قبل النص الصريح
تستقبل دالة AEAD الرسالة والبيانات المرتبطة والمفتاح وnonce، ثم تعيد النص المعمى والوسم. تحسب دالة الفك الوسم المتوقع وتقارنه في زمن ثابت، ولا تعيد النص الصريح إلا بعد النجاح.
يجب أن يكون زوج المفتاح وnonce فريداً لكل عملية تعمية. تغيير طول الوسم لا يفتح نطاق nonce جديداً. تؤدي إعادة الاستخدام إلى كشف الفرق الثنائي بين رسالتين، وتسمح باستعادة الحالة الداخلية في حالة الفشل الموصوفة. يمكن أن يكون nonce علنياً أو قابلاً للتوقع؛ الشرط المركزي هو عدم تكراره مع المفتاح نفسه.
يعطي RFC حدوداً للاختيار العشوائي. تستطيع AEGIS-128L وAEGIS-128X معالجة ما يصل إلى 2^48 رسالة تحت مفتاح واحد باحتمال تصادم يقارب 2^-33. ولا يرى التحليل حداً عملياً لـ AEGIS-256 وAEGIS-256X. لكن غياب الحد العملي يصف خطر التصادم عند التوليد الصحيح، ولا يمنح إذناً بالتكرار المتعمد.
الواجب الثاني هو حراسة المخرج. إذا فشل الوسم، فلا يجوز إخراج النص غير المتحقق أو الوسم المحسوب، ويجب الكتابة فوق مخزن النص قبل العودة. إذا أرسل التطبيق جزءاً إلى محلل أو سجل أو callback أو قاعدة بيانات قبل القرار النهائي، فقد تجاوز البوابة حتى لو أعاد الاستدعاء خطأً في النهاية.
لذلك يربط إيصال العملية بين الدور، والصيغة، وطول الوسم، وهوية المفتاح، وواقعة تخصيص nonce، والترميز غير الملتبس للبيانات المرتبطة، ونتيجة التحقق، وأي أثر جانبي مبكر. يتحقق الوسم من بايتات تحت مفتاح؛ ولا يراقب بنية تطبيق تصرفت سلفاً.
نمط التدفق يتخلى عن دليل التوثيق قصداً
ينشئ RFC 10032 التدفق بتعمية رسالة كلها أصفار بلا بيانات مرتبطة ثم التخلص من الوسم. ويمكن للتنفيذ حذف مرحلة Finalize. النتيجة تدفق مفاتيح، لا رسالة موثقة.
هذه خدمة مشروعة إذا فهمتها البنية الأعلى. الخطر هو توريث السمعة من الاسم. تعرض القياسات aegis_stream() وaegis_encrypt() تحت عبارة «محمي بـ AEGIS». يحتفظ ترحيل الأداء باسم الخوارزمية بينما يغير الوظيفة. يتوقع فريق لاحق وجود وسم في مكان آخر، لكنه غير موجود؛ لقد ألغي بالتعريف.
يحتاج دور التدفق إلى غرض مفتاح مستقل ونطاق nonce مستقل ونوع مخرج يقول صراحة «تدفق غير موثق». وإذا وفرت بنية أخرى السلامة، فيجب تسمية تلك البنية وتسجيل ترتيبها وحاجزها قبل إخراج النص.
تمتلك MAC الاستثناء الوحيد لإعادة الاستخدام
تمتص دالة MAC البيانات وتنتج وسم 128 أو 256 بت. وهي الدالة الوحيدة التي يسمح RFC فيها بإعادة استخدام زوج (المفتاح، nonce) مع مدخلات مختلفة.
الاستثناء يخص الدالة، لا عائلة AEGIS كلها. يمكن لسياسة nonce موحدة أن تنقل الإذن إلى التعمية. لن يكتشف القلب التشفيري خطأ السلطة، وسيستمر في الحساب.
للوسم حدود سلبية أيضاً. لا يجوز استخدامه كدالة hash عندما يكون المفتاح معروفاً، لأن بالإمكان بناء مدخلات تتصادم في الحالة. ولا يجوز استعماله لاشتقاق المفاتيح لأن انتظام توزيعه غير مضمون. طوله لا يحوله إلى بصمة محتوى أو سر جديد.
يجب جعل الفصل قابلاً للتنفيذ: معرّفات مفاتيح مرتبطة بـ AEAD أو STREAM أو MAC؛ تسميات اشتقاق مختلفة؛ موزعات nonce مستقلة؛ ورفض المفتاح عند باب دور آخر. التذكير في التوثيق ليس مستوى تحكم.
طول الوسم والبيانات المرتبطة قراران للبروتوكول
يسمح RFC بوسم 128 أو 256 بت. في لعبة الارتباط الموصوفة، يقدم الأول نحو 64 بت من أمان التزام المفتاح، والثاني نحو 128 بت. لا يكشف رقم IANA أيهما استُخدم.
يعتمد الالتزام أيضاً على من يسيطر على البيانات المرتبطة. تكون AEGIS كاملة الالتزام في الحالة المقيدة التي لا يسيطر فيها الخصم على هذه البيانات. أما حين يستطيع تغييرها، فيبين التحليل المرجعي إمكانية العثور بكفاءة على عدة مفاتيح تتحقق مع النص المعمى الموثق نفسه. يستطيع بروتوكول يحتاج خاصية أقوى تمرير البيانات عبر دالة مقاومة للتصادم والصورة السابقة، أو ربط ترميز واضح بحقل info في KDF وفق القيود المحددة.
هذه قرارات فوق مستوى البدائية. على البروتوكول أن يحدد الحقول، وطريقة تسلسلها، ومن يتحكم بها، وما الخاصية المطلوبة. توثق البدائية البايتات المعطاة لها، لا المعنى المؤسسي الذي يضيفه التطبيق.
متجهات الاختبار لا تصل إلى سلسلة الحيازة
تثبت متجهات RFC 10032 الواسعة أن تنفيذاً يعطي المخرج المتوقع لمدخل ثابت. وتثبت اختبارات التوافق أن تنفيذين يتفقان على الحالات. لكنها لا تثبت أن الإنتاج استدعى الباب الصحيح أو أغلق مسار الفشل.
يجب أن تحاول الاختبارات السلبية خلط الأدوار: تقديم مفتاح دور إلى دور آخر وانتظار الرفض؛ تكرار nonce للتعمية مع تغيير طول الوسم؛ التأكد من أن استثناء MAC لا يعدل موزع AEAD؛ وسم التدفق بأنه غير موثق؛ إفساد النص والوسم والبيانات المرتبطة ومراقبة عدم خروج أي نص أو أثر؛ تمرير وسم MAC إلى واجهات hash وKDF وانتظار رفضه؛ والتحقق من الملف التنفيذي ومسار CPU والعدادات المنفصلة.
تعتمد مقاومة هجمات التوقيت والطاقة وحقن الأعطال على تنفيذ AESRound الفعلي ونموذج التهديد. ويذكر RFC إمكان مسح المفتاح المؤقت بعد التهيئة لأن العمليات اللاحقة تستخدم الحالة. لا يثبت ذلك أن المترجم أو المكتبة نفذا المسح؛ فهذا دليل من الشفرة العاملة.
يجمع إيصال الدور الأدنى بين غرض التطبيق ونموذج التهديد، والدور، والصيغة والتوازي، وطول الوسم، وهوية المفتاح وغرضه، ونطاق nonce وتخصيصه، ومخطط البيانات المرتبطة، وإصدار المكتبة ومسارها، والتحقق والمسح، وحاجز المخرجات، والعدادات، وقرار التطبيق.
تسمح عقيدة الحد الأدنى للمواصفة عند Lu Heng ببدائية مشتركة من دون منح السجل سلطة استعمالها. السجل يسمي، والمكتبة تنفذ دوراً، والبروتوكول يبني المعنى، والتطبيق يجيز النتيجة. وتمنع طبقات الواقع RFC أو اختباراً أو وسماً من استعارة سلطة الطبقة التالية.
درس RFC 10032 التشغيلي ليس أن AEGIS تؤدي ثلاث وظائف فحسب، بل أن الآلية المشتركة لا توحد الواجبات. بقي الاسم؛ ويجب أن تبقى الإيصالات منفصلة.
المصادر
- النص الكامل لـ RFC 10032
- سجل نشر RFC 10032
- سجل IRTF لـ RFC 10032
- تاريخ وثيقة RFC 10032
- سجل IANA لمعاملات AEAD
- RFC 5116: واجهة التعمية الموثقة
- RFC 9771: خصائص خوارزميات AEAD
- RFC 5743: وثائق مسار IRTF
- RFC 7841: مسارات RFC وحالاتها
- NIST FIPS 197: معيار التعمية المتقدم
- RFC 6234: خوارزميات hash الآمنة
- RFC 5869: HKDF
- Lu Heng: أولوية الشفرة العاملة
- Lu Heng: الحد الأدنى للمواصفة والتبني الطوعي
- Lu Heng: طبقات الواقع والسلطة الرمزية
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
