Почему большее число бит ключа не делает VPN безопаснее

Реклама говорит 256 бит, другой продукт говорит 128 бит, и вывод кажется очевидным, пока не заметишь, что числа описывают разные вещи. Ключ симметричного шифра, открытый ключ сертификата и параметр обмена ключами не измеряются одной шкалой. Ни один из них не охватывает вопрос, проверил ли клиент сервер вообще. Число — это реальная информация, и она гораздо уже, чем намекает окружающий его маркетинг.

Прежде чем что-либо сравнивать, спросите, какой ключ считают и что он защищает.

Три ключа с тремя задачами

Шифр данных шифрует полезную нагрузку туннеля, и его ключ выводится заново для каждой сессии. Открытый ключ сертификата доказывает подлинность конечной точки при аутентификации. Этап обмена ключами, обычно эфемерный вариант Diffie-Hellman, устанавливает общий секрет, который затем ни одна сторона не может восстановить. У каждого свои допущения о стойкости и свои соглашения о размере.

Поэтому 256 рядом с 2048 рядом с 32 нельзя упорядочить по величине; это ответы на разные вопросы.

Даже внутри одной роли число говорит что-то лишь в отношении используемого семейства алгоритмов.

Где число помогает, а где останавливается

Внутри одного алгоритма больший ключ повышает стоимость перебора, а опубликованные рекомендации задают минимумы для ключей сертификатов по мере изменения вычислительной мощности. Это законное и узкое сравнение: AES-128 и AES-256 оба противостоят прямой атаке с большим запасом, поэтому разница на практике редко становится решающим фактором.

За пределами этого сравнения число ничего не предсказывает об ошибках конфигурации, проверке сертификатов или версии протокола.

Читайте весь согласованный набор

То, что соединение действительно использует, — это набор: режим шифра, конструкция целостности или аутентифицированного шифрования, группа обмена ключами и метод аутентификации. Современный режим AEAD с правильным рукопожатием — иное предложение, чем более старый режим с отдельным MAC, даже если заявленный размер ключа совпадает.

openvpn --show-ciphers | head -20
openvpn --show-tls | head -20
openssl x509 -in server.crt -noout -text | grep -E 'Public-Key|Signature Algorithm'
wg show

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

Части, которые число никогда не измеряет

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

Проверка партнёра — третий и самый значимый пункт. У клиента, принимающего любой сертификат, сильный шифр обёрнут вокруг неаутентифицированного партнёра, и это хуже, чем скромный шифр с правильной проверкой. Проверьте эти три вещи до числа, и число займёт подобающее место.