Чому довший ключ 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 не змінює нічого важливого, а вгадування нової директиви на одному клієнті — це спосіб перетворити робочий тунель на зламаний. Перевірте зміну на одному клієнті й одному сервері, перш ніж торкатися решти парку. Тримайте старий профіль доступним для відкату, доки новий шифр не пройде повний цикл з'єднання.

Зберігайте перевірку сертифікатів і автентифікацію облікових записів під час зміни. Вони відповідають на різні питання: успішний вхід не може розширити блок, а кращий шифр даних не виправдовує довіри не тому серверу.

Завершіть перевірку, знову прочитавши узгоджений шифр на новому з'єднанні, і потім переконайтеся, що старий шифр більше не приймається. Якщо сторона все ще пропонує його, міграція не завершена, хоч би що казав профіль на іншому боці.