AES-GCM أم ChaCha20-Poly1305: اختيار شيفرة بيانات VPN
AES-GCM هو الخيار البديهي على الخوادم المدعومة عتادياً، وChaCha20-Poly1305 هو الذي يعمل جيداً بدونها. قد يقرر بروتوكولك نيابة عنك.
الاسمان بناءان من نوع AEAD، وكلاهما معياري، وعلى خادم x86 حديث سيشبع أي منهما رابط جيجابت دون جهد ملحوظ. يصبح الاختيار اعتباطياً عندما تخرج من ذلك الخادم: فالمساحات الرخيصة والهواتف الأقدم والأجهزة الافتراضية غالباً ما تفتقر إلى تسريع AES، وهناك يكون الفرق كبيراً. لذا فالمقارنة ليست أي شيفرة أسرع، بل أي شيفرة تعمل جيداً على هذه المجموعة من نقاط النهاية، وهل يقدم البروتوكول خياراً أصلاً.
المهمة نفسها، والأنوية مختلفة
يمنح البناءان السرية والسلامة في تمريرة واحدة ويوثقان البيانات المرتبطة، ولهذا تستخدمهما بروتوكولات VPN للقناة البياناتية. الفرق في الداخل: AES-GCM هو شيفرة كتل AES في وضع عدّاد مع موثّق كثير حدود على GF(2^128)، بينما ChaCha20-Poly1305 شيفرة تيار بمفتاح 256 بت وموثّق منفصل لمرة واحدة.
ما يهم تشغيلياً مشترك: كلاهما يفشل فشلاً كارثياً عند إعادة استخدام nonce، وكلاهما يحتاج إلى إدارة فضاء nonce لكل مفتاح، ولا يصلح أي منهما نظيراً يوثق الشيء الخطأ. الملف الذي يقول AES-256-GCM ليس أكثر أماناً من الذي يقول CHACHA20-POLY1305؛ كلاهما قوي عندما يكون التنفيذ صحيحاً.
حيث يفوز AES-GCM
لـAES تعليمات مخصصة على معظم المعالجات الحديثة: AES-NI على x86، وامتدادات التشفير على ARMv8، وما يماثلها على تصاميم POWER وRISC-V الحديثة. عند وجودها يشغّل GCM عدة كتل بالتوازي في كل صنف دورات، ويصبح تنفيذ البرمجية غير ذي صلة. هذه هي الحالة الشائعة للخوادم والحواسيب والهواتف الحالية، ولهذا فإن استخدام AES نصيحة افتراضية معقولة في مركز البيانات.
المشكلة في الحالة من الدرجة الثانية. بدون تعليمات مخصصة يكون AES في البرمجيات بطيئاً، والتطبيقات البرمجية المعتمدة على الجداول هي التي لها تاريخ طويل من مشكلات توقيت الذاكرة المؤقتة. مجمّع VPN يعمل داخل جهاز افتراضي لا يعرض مضيفه أعلام AES للضيف هو هذه الحالة بالضبط، ويسهل إغفاله لأن معالج المضيف يمتلك الميزة.
افحص ما تراه العملية فعلاً لا ما يدعمه المعالج: grep -o aes /proc/cpuinfo | head -1 على Linux، أو علم الميزة المكافئ في طراز المعالج لدى المراقب الافتراضي.
حيث يفوز ChaCha20-Poly1305
ChaCha20 سريع في البرمجيات المحمولة لأنه لا يستخدم سوى الجمع والدوران وXOR، وتتجنب تطبيقاته عمداً عمليات البحث في الجداول المعتمدة على الأسرار. على جهاز بلا تسريع AES يمثل ذلك ميزة جوهرية، ولهذا اختاره WireGuard: فـوصف بروتوكول WireGuard يدرج ChaCha20-Poly1305 شيفرةً للبيانات دون بديل.
هذا الخيار الواحد يخبرك بشيء مفيد: على العتاد الذي يُسرَّع فيه AES يتنازل WireGuard عن بعض الإنتاجية مقارنة بـAES-GCM، وقد قبل مؤلفوه ذلك مقابل سلوك متوقع على الهواتف والموجهات المنزلية ومضيفات الحاويات. إذا كان أسطولك في معظمه صناديق ARM صغيرة فالتبادل في صالحك.
الحالة المعاكسة هي مجمّع x86 مشغول، حيث يكون AES-GCM مع AES-NI المسار الأسرع والأفضل دعماً، وحيث يستهلك ChaCha20 معالجاً قابلاً للقياس لكل جيجابت. لا يمثل أي من البناءين ضعفاً؛ السؤال هو أيهما ينفذه عتادك بتكلفة أقل.
ما يسمح لك بروتوكولك باختياره فعلاً
| Protocol | What you get |
|---|---|
| WireGuard | ChaCha20-Poly1305 only; no negotiation |
| OpenVPN 2.5 and later | Data channel negotiated from data-ciphers: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 |
| IPsec / IKEv2 | AES-GCM as a combined-mode transform, or ChaCha20-Poly1305 where both peers implement it |
| OpenVPN control channel | TLS decides; TLS 1.3 offers AES-GCM and ChaCha20-Poly1305 suites |
لاحظ الانقسام في OpenVPN: تُتفاوض قناة التحكم وقناة البيانات بشكل منفصل، فالحزمة التي تراها في TLS لا تقول شيئاً عن الشيفرة التي تحمي حمولتك. يذكر ملخص الجلسة الاثنين معاً، وقراءة واحدة فقط من الاثنتين مصدر شائع للالتباس.
في OpenVPN تأتي شيفرة قناة البيانات من قائمة data-ciphers على الطرفين. إذا لم تتقاطع قائمة الخادم وقائمة العميل فإن الاتصال إما يتراجع إلى ما يسمح به data-ciphers-fallback أو يفشل كلياً، ويُلام ذلك الفشل عادةً على الطبقة الخاطئة. ضع القائمة نفسها على الجانبين، ثم أكّد النتيجة المتفاوض عليها في السجل بدل افتراض أن ترتيب القائمة قد احتُرم.
قرر انطلاقاً من ثلاث حقائق عن النشر
أولاً، هل تمتلك نقاط النهاية تسريع AES؟ إذا كان كل نظير يمتلكه فإن AES-GCM هو الخيار الأرخص والافتراضي في معظم الإعدادات المصانة. وإذا كانت حصة معتبرة موجهات صغيرة أو هواتف قديمة فإن ChaCha20-Poly1305 يمنع ذيل الأسطول من أن يصبح حد السعة.
ثانياً، هل يقدم البروتوكول خياراً أصلاً؟ مع WireGuard اتُّخذ القرار نيابة عنك، والعمل المفيد هو التحقق من أن الأدوات المحيطة لا تستبدل شيئاً آخر بصمت. أما مع OpenVPN وIPsec فالجواب سطر إعداد ونتيجة تفاوض تُسجَّل.
ثالثاً، هل يستطيع الطرفان الاتفاق؟ الشيفرة التي لا ينفذها أحد النظيرين ليست قرار أداء بل انقطاع. ولهذا تهم قائمة النظيرين أكثر من أي قياس أداء: الأسطول المختلط يحتاج تقاطع القدرات لا تفضيل أسرع جهاز.
إن قِست فعلاً فاحتفظ بالجهاز ونقطة النهاية والحمل متطابقة وغيّر شيئاً واحداً. الاختبار الذي يقارن خادمين في منطقتين مختلفتين يقيس المسار لا الشيفرة، وقياس حاسوب محمول لا يقول شيئاً عن مضيف حاوية أعلام معالجه محجوبة. قارن، ثم اكتب أي شيفرة فُوّضت فعلاً: ذلك السجل أثمن من القياس.