اختيار AEAD لأنظمة الإنتاج

يُعد AES-GCM خيار AEAD الافتراضي الصحيح لمعظم أنظمة الإنتاج. فهو مدعوم بتسريع العتاد عبر AES-NI في جميع معالجات x86 وARM64 الحديثة تقريبًا، ويحظى بدعم واسع في حزم TLS ومكتبات التشفير، كما يستفيد من تحليل تشفيري مكثف وخبرة واسعة في النشر الفعلي.

يستخدم AES-GCM قيمة nonce بحجم 96 بت. ومع إنشاء nonce عشوائيًا، يُبلَغ حد عيد الميلاد بعد نحو 2^32 رسالة باستخدام المفتاح نفسه، وعندها يصبح احتمال تصادم nonce غير ضئيل. وفي الأنظمة ذات الحجم الكبير، تُعد إدارة nonce باستخدام عدّاد أو تدوير المفتاح بعد 2^32 رسالة أمرًا ضروريًا.

يُعد ChaCha20-Poly1305 الخيار الصحيح عند عدم توفر AES-NI أو عندما يكون إنشاء nonce غير موثوق. فهو سريع برمجيًا، وثابت الزمن بطبيعته، أي مقاوم للقنوات الجانبية للتوقيت، كما أنه مجموعة التشفير الإلزامية في TLS 1.3 للبيئات التي لا تدعم عتاد AES.

عندما يُحتمل إعادة استخدام nonce أو عندما يجب إنشاؤه حتميًا، كما في الخدمات عديمة الحالة أو تغليف المفاتيح، يكون AES-GCM-SIV (RFC 8452) هو الخيار الصحيح. فهو يوفر مقاومة لإساءة استخدام nonce بكلفة أداء محدودة مقارنةً بـ AES-GCM القياسي.

يُعد AEGIS-128L الخيار الصحيح عند الحاجة إلى أقصى معدل نقل للتشفير، مع ضمان توفر AES-NI في جميع أهداف النشر. وتُعد أجهزة الشبكات ذات النطاق الترددي العالي، ومجمّعات VPN، وأنظمة تشفير التخزين مرشحةً مثالية عندما يوفر AEGIS مكاسب أداء ملموسة مقارنةً بـ AES-GCM.

يوفر AES-128 أمانًا بمستوى 128 بت، وهو ما يُعد كافيًا لجميع تهديدات الحوسبة الكلاسيكية الحالية والمتوقعة. أما AES-256 فيوفر هامشًا إضافيًا لمواجهة التطورات المستقبلية، وتطلبه بعض أطر الامتثال، مثل تصنيف TOP SECRET ضمن NSA Suite B. وبالنسبة إلى معظم التطبيقات، يكفي AES-128، كما أنه أسرع قليلًا.

يستخدم AES-GCM قيم nonce بحجم 96 بت، بينما يستخدم AES-GCM-SIV أيضًا قيم nonce بحجم 96 بت. ويستخدم XSalsa20، المستخدم في secretbox من libsodium، قيم nonce بحجم 192 بت، مما يجعل إنشاء nonce عشوائيًا آمنًا لعدد أكبر بكثير من الرسائل باستخدام المفتاح نفسه. وتقلل قيم nonce الأكبر خطر إعادة الاستخدام العرضية في الأنظمة ذات الحجم الكبير.

استخدم مكتبات AEAD الراسخة بدلًا من تنفيذ الوحدات الأساسية مباشرةً. توفر libsodium واجهة AEAD بسيطة (crypto_aead_aes256gcm_encrypt, crypto_aead_chacha20poly1305_ietf_encrypt). وتغلف Google Tink وحدات AEAD الأساسية مع تدوير المفاتيح وإصدارها. وتتعامل مكتبات TLS الأصلية للغات البرمجة مع AEAD تلقائيًا لتأمين النقل.

يُعد AES-CBC مع HMAC-SHA256 منفصل، بترتيب EtM، مقبولًا لكنه قديم. ويبسّط الترحيل إلى AES-GCM التنفيذ باستبدال وحدتين أساسيتين بوحدة واحدة، كما يلغي خطر التركيب غير الصحيح. وينبغي إعادة تشفير البيانات الساكنة المشفرة باستخدام CBC-HMAC بـ AES-GCM أثناء تدوير المفاتيح المجدول.

ينبغي اختبار تطبيقات AEAD باستخدام متجهات الاختبار الرسمية من NIST لـ AES-GCM ومن RFC 8439 لـ ChaCha20-Poly1305. اختبر دائمًا أن يؤدي فشل التحقق من وسم المصادقة إلى إعادة التشفير خطأً بدلًا من نص صريح جزئي. وتُعد معالجة الأخطاء غير الصحيحة عيبًا شائعًا في التنفيذ.

اختر AES-GCM عند توفر AES-NI وضمان فرادة قيم nonce. واختر ChaCha20-Poly1305 عند غياب AES-NI أو عندما تكون قيم nonce أقل موثوقية. واختر AES-GCM-SIV عندما تكون إعادة استخدام nonce مصدر قلق. واختر AEGIS عندما يكون أقصى معدل نقل مع ضمان توفر AES-NI هو الأولوية. ولا تختر أوضاعًا غير AEAD للأنظمة الجديدة مطلقًا.

AES-GCM هو الخيار الافتراضي. ويغطي ChaCha20-Poly1305 البيئات التي لا يتوفر فيها AES-NI. ويتعامل AES-GCM-SIV مع البيئات غير الآمنة فيما يتعلق بـ nonce. ويزيد AEGIS إلى أقصى حد من معدل النقل عند ضمان توفر AES-NI. استخدم مكتبات مثل libsodium أو Tink بدلًا من تركيب الوحدات الأساسية يدويًا. واختبر دائمًا باستخدام متجهات الاختبار الرسمية، وتحقق من معالجة حالات فشل المصادقة بشكل صحيح.