Криптографическая гибкость — это способность перевести протокол с одного криптографического набора на другой, сохраняя чёткие обязательства по безопасности. В обмене сообщениями это означает больше, чем добавление названия нового алгоритма. Старые клиенты, получатели не в сети, сохранённые сообщения и связанные устройства должны вести себя предсказуемо во время перехода.
В RFC 7696 IETF гибкость алгоритмов описывается как задача миграции, затрагивающая идентификаторы, реализации и эксплуатационные изменения. Номер версии помогает определить, что используется; сам по себе он не делает миграцию безопасной.
Три версии, которые легко перепутать
У мессенджера могут быть версия приложения, версия протокола передачи и идентификатор криптографического набора. Они отвечают на разные вопросы:
| Идентификатор | Что он сообщает проверяющему | Чего он не доказывает |
|---|---|---|
| Выпуск приложения | Какая сборка программы установлена | Что каждая беседа использует новейший протокол |
| Версия протокола | Какой формат сообщений и правила состояния применяются | Что реализация правильно соблюдает эти правила |
| Идентификатор алгоритма или набора | Какие криптографические компоненты выбраны | Что согласование нельзя принудительно понизить |
В примечаниях к выпуску эта связь должна быть явной. Фраза «выпущено новое шифрование» неоднозначна, если его используют только новые беседы или если старый связанный клиент вызывает переход к прежнему режиму.
Что должна определять безопасная миграция
Начните с конкретного сценария: Алиса обновляется сегодня, а Боб остаётся не в сети со старым телефоном. Алиса отправляет сообщение, а позже добавляет второе устройство. Что должно принимать, хранить и отображать каждое устройство?
Проект, который можно проверить, отвечает как минимум на следующие вопросы:
- Как каждая сторона узнаёт о поддерживаемых другой стороной версиях?
- Аутентифицируется ли выбранная версия как часть сеанса?
- Что происходит, если общей приемлемой версии нет?
- Может ли злоумышленный ретранслятор удалить сведения о возможности и вызвать более слабый режим?
- Остаются ли старые сообщения читаемыми и какие старые ключи ещё необходимы?
- Возвращает ли восстановление резервной копии устаревшее состояние протокола?
- Когда устаревшие алгоритмы будут отключены, а не просто объявлены нежелательными?
Явный сбой часто безопаснее незаметного перехода в режим, которого пользователь не намеревался использовать. Но точное поведение при сбое и восстановлении следует документировать, чтобы люди не обходили проблему переходом на незащищённый канал.
Практическая матрица испытаний обновления
Обновление безопасности требует большего, чем успешный чат между двумя свежими установками. Проверьте эти случаи с нечувствительными данными:
| Испытание | Какие свидетельства записать |
|---|---|
| Новый клиент общается со старым | Выбранный протокол или явный результат несовместимости |
| Получатель не в сети во время обновления | Поведение доставки и расшифрования после подключения |
| Возвращается старое связанное устройство | Может ли оно читать, отправлять или навязывать неожиданный режим |
| В группу добавляют несовместимого участника | Явная политика группы и видимое пользователю состояние |
| Резервную копию восстанавливают после прекращения поддержки | Отклоняется ли неподдерживаемое состояние или переносится в новое |
| Метаданные версии подделаны | Ошибка аутентификации вместо незамеченного понижения |
Это критерии оценки, а не утверждения, что названный продукт прошёл испытания. Сохраняйте идентификаторы сборок и наблюдаемые результаты, чтобы позже отличить регрессию от изменения документации.
Как понимать названия протоколов Livara
В своей документации по безопасности Livara называет LVR1 протоколом личных чатов, а LGS1 — частных групп. Эти названия разграничивают обязанности; их не следует считать доказательством независимой стандартизации или аудита. Страница также обсуждает поведение клиентов или групп, которые не могут выполнить предварительные требования зашифрованного режима.
Следующими полезными свидетельствами были бы спецификация с версиями, тестовые векторы, правила совместимости и результаты проверки, привязанные к определённому выпуску. Proof Lab прямо указывает более узкие рамки своей демонстрации. Проверка примитивов в браузере — не то же самое, что испытание каждого пути миграции в приложении.
Что делать пользователям во время обновления шифрования
Обновляйте поддерживаемые клиенты, читайте уведомления безопасности о совместимости устройств и обращайте внимание на изменившиеся индикаторы идентичности или состояния шифрования. Не считайте, что новый значок приложения означает новую защиту всех старых групп и резервных копий. Если продукт не может объяснить, для каких данных изменилась защита, спросите об этом перед передачей чувствительных материалов.
Хорошая криптографическая гибкость делает изменения проверяемыми. Она определяет, что изменилось, как стороны это согласуют, что может пойти не так и когда старый механизм перестаёт приниматься.
