CFB1 در برابر CFB8 در برابر CFB128: اندازه بازخورد است، نه اندازه کلید
عددی که پس از 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 بیتی. این یک قرارداد نام‌گذاری API از یک شاخه است، نه ادعای اینکه هر کتابخانه، قالب فایل یا رابط گرافیکی این اختصار را به یک شکل باز می‌کند. سرآیند یا مستندات نسخه‌ای را که پیش روی دارید بررسی کنید.
اگر نمایه‌ای قدیمی CFB بگوید و طرف مقابل آن را بپذیرد، پارامترهای مذاکره‌شده جایی ثبت می‌شوند: در یک گزارش، در یک تخلیه پیکربندی، در پاسخ یک API. آن‌ها را بخوانید، نه اینکه اندازه قطعه را از یک رشته نمایشی استنتاج کنید.
آنچه نام یک حالت به شما نمی‌گوید
نام رفتار رمزنگاری را توصیف می‌کند و بس. VPN همچنان به محافظت یکپارچگی، استخراج کلید و احراز هویت طرف مقابل نیاز دارد و CFB هیچ‌یک از آن‌ها را فراهم نمی‌کند. جایگزینی CFB8 با CFB1 هم تغییری ظاهری نیست: رفتار روی شبکه متفاوت است و هر دو طرف باید همان ساختار را پشتیبانی کنند. نامی در یک کتابخانه هم ثابت نمی‌کند که دروازه مستقرشده آن را برای کانال داده خود می‌پذیرد.
برای هر چیزی که نگهداری می‌شود، از چیدمان کامل حفاظت پروتکل و سیاست اپراتور استفاده کنید و نسخه‌های کتابخانه و دروازه، گزینه دقیق و نتیجه مذاکره‌شده را ثبت کنید. نام قدیمی توضیح می‌دهد که چه می‌خوانید؛ اما بازگرداندن آن پیکربندی را توجیه نمی‌کند.