لماذا لا يصلح مفتاح Blowfish الأطول كتلة من 64 بت

يقدّم ملف تعريف VPN خيار Blowfish بمفتاح من 448 بت، ويقترح أحدهم استخدام أطول مفتاح للإبقاء على التشفير. طول المفتاح حقيقي، لكنه الرقم الخطأ الذي ينبغي تحسينه. يحوّل Blowfish كتلًا من 64 بت مهما كان طول المفتاح، وعرض الكتلة هو ما يحدّ من كمية حركة المرور التي يمكن لمفتاح واحد حمايتها بأمان. نفّذ الفحوص أدناه بالترتيب وتوقّف عند أول فحص يبرّئ الخدمة، لأن خطوة لاحقة لا تستطيع إصلاح خطوة سابقة.

تحقق مما يتفاوض عليه الطرفان فعليًا

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

إذا كان التشفير المتفاوض عليه هو AES-GCM أو ChaCha20-Poly1305، فتوقّف هنا. تستخدم هذه البنى كتلة من 128 بت وتصادق على الحمولة، لذا لا تنطبق عليها حجة التصادم عند 64 بت أدناه.

افصل طول المفتاح عن عرض الكتلة

يقبل Blowfish مفاتيح من 32 إلى 448 بت، و توثّق وثائق مؤلف الخوارزمية الرقمين بشكل منفصل. المفتاح هو السر؛ والكتلة هي وحدة التحويل. السر الأطول يجعل التخمين أصعب ولا يفعل شيئًا لعرض الكتلة التي يعالجها التشفير.

في وضع CBC يُطبَّق التشفير على كتل ذات عرض ثابت، مربوطة بكتلة النص المشفّر السابقة ومبطّنة في النهاية. بالنسبة إلى Blowfish يكون ذلك العرض 64 بت، أي ثمانية بايتات. يمكن أن يكون جدول المفاتيح بأي حجم تريده؛ ومع ذلك تتقدم السلسلة ثمانية بايتات في كل مرة.

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

طبّق حساب أعياد الميلاد على حجم الكتلة

لكتلة من 64 بت مقياس أعياد ميلاد يقارب 2^32 كتلة مشفّرة تحت مفتاح واحد قبل أن تصبح التصادمات محتملة. تحمل كل كتلة ثمانية بايتات، لذا فإن المقياس نفسه يقارب 2^35 بايت، أو 32 GiB من البيانات تحت مفتاح واحد.

تعامل مع ذلك كمقياس، لا كحصة. التصادمات احتمالية، وما إذا كان أحدها سيكشف شيئًا يعتمد على الوضع ونمط حركة المرور وعلى ما إذا كان المهاجم يستطيع التعرف على النص الصريح المحيط أو التأثير فيه. البايت الأول بعد 32 GiB ليس حدث فك تشفير، وأول 32 GiB ليست معتمدة كآمنة.

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

قرّر ما إذا كانت إعادة استخدام CBC مهمة هنا

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

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

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

استبدل التشفير، لا المفتاح

انقل الخدمة إلى تشفير AEAD مدعوم وتأكد من أن الطرفين وإصداريهما وخلفياتهما التشفيرية تستطيع التفاوض عليه. لا يغيّر مفتاح Blowfish الأطول شيئًا مهمًا، وتخمين توجيه جديد على عميل واحد هو الطريقة التي يتحول بها نفق عامل إلى نفق معطّل. اختبر التغيير على عميل واحد وخادم واحد قبل لمس بقية الأسطول. أبقِ ملف التعريف القديم متاحًا للرجوع حتى يجتاز التشفير الجديد دورة اتصال كاملة.

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

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