CFB1 مقابل CFB8 مقابل CFB128: الحجم بعد CFB تغذية راجعة وليس حجم المفتاح
الرقم الذي يلي CFB هو خطوة تغذية راجعة، لا طول مفتاح: تستخدم CFB1 و CFB8 و CFB128 كتلة من 128 بت. اقرأ الأسماء القديمة دون اختراع مفاتيح ضعيفة.
يحمل اسم مثل AES-256-CFB1 رقمين، وهما يجيبان عن سؤالين مختلفين. الرقم 256 هو طول مفتاح AES. أما الرقم 1 فهو حجم التغذية الراجعة، أو القطعة، في CFB، وهو خاصية لكيفية تقدّم النمط لحالته. وإذا قرُئ الرقم 1 على أنه طول مفتاح، بدا الاسم كإعداد كارثي، ولهذا يعود السؤال دائماً.
حدّد أيّاً من ثلاث كميات تنظر إليها قبل أن تحكم على الاسم: حجم المفتاح، أو حجم الكتلة، أو حجم القطعة. الأولى وحدها معامل أمني بالمعنى المعتاد.
ثلاثة أرقام، ثلاث كميات
يقبل AES مفاتيح بطول 128 أو 192 أو 256 بت، وله كتلة من 128 بت أيّاً كان اختيارك. حجم الكتلة ينتمي إلى AES لا إلى النمط. ولاحقة CFB هي الكمية الثالثة: مقدار البيانات التي يستهلكها النمط ويعيد تغذيتها في كل خطوة. وتدرج وثائق OpenSSL الخاصة بـ AES أحجام الإزاحة هذه صراحةً لمتغيّرات CFB.
يعيد CFB1 تغذية بت واحد في كل مرة، ويعيد CFB8 بايت واحداً، ويعيد CFB128 كتلة كاملة. والثلاثة تستخدم في الداخل الشفرة الكتلية نفسها ذات 128 بت؛ والذي يتغير هو عدد البتات المستخدمة من كل كتلة محسوبة في كل عملية. ولهذا تغيّر اللاحقة التكلفة وسلوك التخزين المؤقت لا قوة المفتاح.
| Name | Key | AES block | Feedback |
|---|---|---|---|
| AES-256-CFB1 | 256 bits | 128 bits | 1 bit |
| AES-256-CFB8 | 256 bits | 128 bits | 8 bits |
| AES-256-CFB128 | 256 bits | 128 bits | 128 bits |
لماذا لا يتغير حجم الكتلة أبداً
AES شفرة كتلية بكتلة ثابتة من 128 بت، والأنماط إنشاءات تُبنى حولها. ولا واحد منها يصغّر الكتلة لتطابق حجم القطعة. فتنفيذ CFB1 لا يزال يحسب كتلة AES كاملة ويأخذ بتاً واحداً من الناتج. وتُهمل البتات الأخرى في تلك الخطوة، وهنا بالضبط تقع تكلفة الكفاءة.
إذاً لا تعني التغذية الراجعة ببت واحد مفتاحاً ببت واحد، ولا يمكن ترتيب اسم حسب لاحقته. فCFB128 ليست أقوى أربع مرات من CFB32؛ إنها تعالج قطعاً أكبر.
ما الذي يغيّره حجم القطعة فعلاً
يغيّر حجم القطعة مقدار النص المشفّر الذي يعاد تغذيته في كل خطوة ومقدار النص الصريح الذي تحمله كل خطوة. ويغيّر أيضاً انتشار الأخطاء وسلوك التخزين المؤقت، وهذا مهم للاستخدام الشبيه بالبث. فالقطع الموجّهة بالبايت تتوافق مع المخازن المؤقتة، والموجّهة بالبت لا تتوافق.
عملياً، البروتوكول هو من يختار النمط لا المشغّل. فـقناة بيانات VPN تستخدم الإنشاء الذي يحدده بروتوكولها، مع حماية تكامل خاصة به، وقائمة مكتبة تخبرك فقط بالأسماء الموجودة.
قراءة تسمية CFB غير المؤهلة
تحتاج تسمية CFB غير المؤهلة إلى سياق تنفيذها. في ترويسات OpenSSL 1.0.2، يكون EVP_aes_128_cfb ماكرو لـ EVP_aes_128_cfb128، مع أسماء بديلة مطابقة لمفاتيح 192 و 256 بت. وهذا اصطلاح تسمية في واجهة برمجة تطبيقات من فرع واحد، وليس زعماً بأن كل مكتبة أو صيغة ملف أو واجهة رسومية توسّع الاختصار بالطريقة نفسها. راجع الترويسة أو التوثيق الخاص بالإصدار الذي أمامك.
إذا قال ملف تعريف قديم CFB وقبله الطرف الآخر، فستُسجَّل المعاملات المتفاوض عليها في مكان ما: في سجل، أو تفريغ إعدادات، أو استجابة واجهة برمجية. اقرأ تلك بدلاً من استنتاج حجم القطعة من نص العرض.
ما لا يخبرك به اسم النمط
يصف الاسم سلوك التشفير ولا شيء غيره. ولا تزال VPN بحاجة إلى حماية التكامل واشتقاق المفاتيح ومصادقة الطرف الآخر، وCFB لا يوفر أياً منها. واستبدال CFB8 بـ CFB1 ليس تغييراً شكلياً أيضاً: فسلوك الشبكة يختلف ويجب أن يدعم الطرفان الإنشاء نفسه. كما أن وجود اسم في مكتبة لا يثبت أن البوابة المنشورة تقبله لقناة بياناتها.
لأي شيء يُصان، استخدم ترتيب الحماية الكامل للبروتوكول وسياسة المشغّل، وسجّل إصدارات المكتبة والبوابة والخيار الدقيق والنتيجة المتفاوض عليها. فالاسم القديم يفسّر ما تقرأه؛ لكنه لا يبرّر إحياء الإعداد.