لماذا لا يجعل الرقم الأكبر للمفتاح شبكة VPN أكثر أمانًا

يقول الإعلان 256 بت، ويقول المنتج الآخر 128 بت، ويبدو الاستنتاج بديهيًا حتى تلاحظ أن الأرقام تصف أشياء مختلفة. مفتاح تشفير متماثل، ومفتاح عام لشهادة، ومعامل لتبادل المفاتيح لا تُقاس على مقياس واحد. ولا يغطي أيٌّ منها ما إذا كان العميل قد تحقق من الخادم أصلًا. الرقم معلومة حقيقية، لكنه أضيق بكثير مما يوحي به التسويق حوله.

اسأل عن المفتاح الذي يُعدّ وما الذي يحميه قبل أن تقارن أي شيء.

ثلاثة مفاتيح بثلاث مهام

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

لهذا لا يمكن ترتيب 256 بجانب 2048 بجانب 32 حسب الحجم؛ فهي إجابات على أسئلة مختلفة.

وحتى داخل دور واحد، لا يقول الرقم شيئًا إلا بالنسبة إلى عائلة الخوارزمية المستخدمة.

أين يفيد الرقم، وأين يتوقف

داخل خوارزمية واحدة، يرفع المفتاح الأكبر كلفة البحث بالقوة الغاشمة، وتضع الإرشادات المنشورة حدًّا أدنى لمفاتيح الشهادات مع تغيّر القدرة الحسابية. هذه مقارنة مشروعة وضيقة: فـAES-128 وAES-256 كلاهما يقاوم الهجوم المباشر بهوامش واسعة، لذا نادرًا ما يكون الفرق هو العامل الحاسم عمليًا.

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

اقرأ حزمة التفاوض كاملة

ما يستخدمه الاتصال فعليًا هو حزمة: نمط تشفير، وبنية سلامة أو تشفير موثّق، ومجموعة تبادل مفاتيح، وطريقة مصادقة. النمط الحديث من نوع AEAD مع مصافحة سليمة أمر مختلف عن نمط أقدم مقترن بـMAC منفصل، حتى عندما يكون حجم المفتاح المعلن متطابقًا.

openvpn --show-ciphers | head -20
openvpn --show-tls | head -20
openssl x509 -in server.crt -noout -text | grep -E 'Public-Key|Signature Algorithm'
wg show

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

أجزاء لا يقيسها أي رقم

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

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