چرا کلید طولانی‌تر 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 هیچ چیز مهمی را تغییر نمی‌دهد و حدس زدن یک دستور جدید روی یک سرویس‌گیرنده همان راهی است که یک تونل کارکننده به تونلی خراب تبدیل می‌شود. تغییر را روی یک سرویس‌گیرنده و یک سرور آزمایش کنید پیش از آنکه به بقیه ناوگان دست بزنید. نمایه قدیمی را تا وقتی رمزنگاری جدید یک چرخه اتصال کامل را پشت سر بگذارد برای بازگشت در دسترس نگه دارید.

در طول تغییر، بررسی گواهی و احراز هویت حساب را حفظ کنید. آن‌ها به پرسش‌های متفاوتی پاسخ می‌دهند: ورود موفق نمی‌تواند بلوکی را پهن‌تر کند و رمزنگاری داده بهتر بهانه‌ای برای اعتماد به سرور اشتباه نیست.

بررسی را با خواندن دوباره رمزنگاری مذاکره‌شده روی یک اتصال تازه و سپس تأیید اینکه رمزنگاری قدیمی دیگر پذیرفته نمی‌شود ببندید. اگر طرفی هنوز آن را ارائه می‌دهد، مهاجرت کامل نشده است، هر چه نمایه طرف دیگر بگوید.