Почему более длинный ключ 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 не меняет ничего важного, а угадывание новой директивы на одном клиенте — это способ превратить работающий туннель в сломанный. Проверьте изменение на одном клиенте и одном сервере, прежде чем трогать остальной парк. Держите старый профиль доступным для отката, пока новый шифр не пройдёт полный цикл подключения.

Сохраняйте проверку сертификатов и аутентификацию учётных записей во время изменения. Они отвечают на разные вопросы: успешный вход не может расширить блок, а лучший шифр данных не оправдывает доверия не тому серверу.

Завершите проверку, снова прочитав согласованный шифр на новом подключении, и затем убедитесь, что старый шифр больше не принимается. Если сторона всё ещё предлагает его, миграция не завершена, что бы ни говорил профиль на другой стороне.