Сравнивайте стоимость определённой операции и доказательства для определённой угрозы, а не просто схему дерева со схемой ключей отправителей.
Messaging Layer Security (MLS) и LGS1 от Livara — не два взаимозаменяемых сертификата безопасности группового чата. MLS — стандарт протокола IETF; LGS1 — документированная схема, специфичная для продукта Livara. Для справедливого сравнения нужно разделять архитектуру, доказательства реализации и поведение, с которым действительно сталкиваются пользователи.
Ключевое различие — общее групповое состояние на основе дерева против ключей отправителей, распространяемых через попарные сеансы. Ни одна из этих меток сама по себе не сообщает, правильно ли конкретное приложение обрабатывает удалённого участника, устройство с устаревшим состоянием или скомпрометированный ключ.
Архитектурное различие
RFC 9420 определяет MLS для асинхронного установления групповых ключей. Он использует храповичное дерево и групповые эпохи, обеспечивая прямую секретность и посткомпрометационную безопасность при указанных условиях. Его древовидная структура сокращает некоторые затраты на обновление ключей по мере роста группы.
Документация по безопасности Livara описывает LGS1 как подписанную цепочку отправителя для каждого участника, распространяемую через попарные сеансы LVR1 и сменяемую при изменении состава. Это заявление о продукте, а не доказательство того, что LGS1 соответствует MLS или имеет такой же анализ.
| Вопрос | MLS | Документация Livara LGS1 |
|---|---|---|
| Общая структура | Храповичное дерево и эпохи | Цепочки отдельных отправителей |
| Обновления ключей | Изменения группового состояния фиксируются в новой эпохе | Новые ключи отправителей распространяются участникам |
| Статус спецификации | Стандарт IETF, RFC9420 | Опубликованное описание конкретного продукта |
| Что ещё нужно оценить | Интеграцию в приложение и реализацию | Полную спецификацию, реализацию и независимые доказательства |
Эта таблица описывает категории схем. Это не тест производительности и не рейтинг безопасности.
Что означает «логарифмический» — и чего не означает
Криптографическое обновление может использовать логарифмическое число зашифрованных компонентов пути дерева, не делая всю работу системы логарифмической. Сообщения по-прежнему нужно распространять, клиенты хранят состояние, а поведение зависит от структуры группы и операций. Старое сравнение «MLS требует O(log N) сообщений, а в LGS1 всё быстрее» смешивало разные затраты и не предлагало измерений.
Архитектура MLS, RFC 9750, рассматривает сервис доставки отдельно от криптографического установления ключей. В ней обсуждаются распространение сообщений и упорядочивание изменений группы. Это разделение важно: вычисления клиента, байты в commit, общий объём серверной рассылки и трафик повторного подключения — разные метрики.
Содержательный отчёт о производительности должен указывать:
- размер группы и число устройств на человека;
- является ли операция обычным сообщением, удалением участника, обновлением ключа или повторным подключением;
- байты, отправленные инициирующим клиентом, отдельно от общего трафика доставки;
- затраченное время, модель устройства, версию реализации и условия сети;
- стоимость пропущенных обновлений и повторных изменений состава.
Без этих подробностей заявления о «миллисекундах», «низких затратах на хранение состояния» или превосходстве при определённом размере группы не обоснованы.
Удаление участника — проверка жизненного цикла
Удаление учётной записи администратором — лишь часть истории безопасности. Клиенты должны согласовать новый состав группы, использовать подходящие свежие ключи и не выдавать их исключённым устройствам. Человек, уже владеющий старым открытым текстом или старыми ключами, может сохранить доступ к старому содержимому; удаление не заставит его копии исчезнуть.
Для любой из систем полезно спросить: после завершения удаления может ли удалённое устройство расшифровать новое тестовое сообщение без чувствительных данных? Может ли участник, который был вне сети, безопасно наверстать изменения? Учитываются ли все устройства учётной записи? Показывает ли интерфейс сбои или изменения состава?
Это предлагаемые вопросы для оценки, а не результаты проведённых здесь тестов. Сравнение продуктов должно публиковать наблюдавшийся результат и проверенную версию, а не приравнивать успешное нажатие администратором кнопки к криптографическому исключению.
Прямая секретность и восстановление зависят от условий
Сохранение защиты старых сообщений после последующей компрометации зависит от вывода из обращения старого секретного материала. Восстановление защиты будущих сообщений зависит от включения свежих секретов после потери атакующим соответствующего доступа. В MLS обработка групповых обновлений — часть этого восстановления; просто отправить обновление не то же самое, что каждый участник его применил. См. соображения безопасности в RFC 9420.
Для схемы с ключами отправителей спросите, как заменяется и заново распространяется скомпрометированное состояние каждого отправителя. Одностороннюю цепочку саму по себе нельзя описывать как автоматически восстанавливающую безопасность против атакующего, знающего её текущее состояние. Попарная защита при повторном распространении имеет значение, но не заменяет полного анализа на уровне группы.
Постквантовые заявления требуют конкретного набора алгоритмов и области охвата
Наборы алгоритмов, определённые в базовом RFC9420, используют классические механизмы с открытым ключом. MLS расширяем, поэтому заявление о конкретной реализации должно указывать фактический набор и расширения, а не объявлять все внедрения MLS навсегда классическими.
Документированное использование LGS1 гибридного распространения LVR1 — иное утверждение, чем независимо проанализированная постквантовая гарантия для каждой групповой операции. FIPS 203 стандартизует ML-KEM; он не сертифицирует весь групповой протокол, включающий его. Оценивайте аутентификацию, изменения состава, компрометацию ключей и реализацию вместе, а не только название KEM.
Что запросить перед выбором продукта
Запросите текущую спецификацию протокола, тестовые векторы и независимую проверку для конкретной версии, включая неустранённые замечания. Затем сравните обычные требования к продукту: поддерживаемые устройства, поведение обновлений, восстановление, роли модерации и данные, сохраняемые серверами.
Архитектура MLS явно рассматривает сервисы приложения и их предположения о доверии. Аналогично модель угроз Livara нужно читать вместе с заявлениями о продукте. Шифрование не делает авторизованных участников заслуживающими доверия, не останавливает снимки экрана и не устраняет все виды метаданных.
Если доказательств нет, записывайте «не установлено», а не автоматически объявляйте схему небезопасной или превосходящей другие. Решение должно отражать риски вашей группы и качество имеющихся доказательств.
Частые вопросы
Является ли LGS1 реализацией MLS?
Опубликованные описания показывают разные архитектуры. Эта статья не определяет LGS1 как реализацию MLS и не заявляет о совместимости.
Требует ли MLS, чтобы все участники одновременно были в сети?
Нет. Асинхронное использование — часть его дизайна. Приложениям всё равно нужны политики для задержанных обновлений, устаревшего состояния и участников, долго отсутствующих в сети.
Решает ли постквантовое распространение ключей вопрос групповой безопасности?
Нет. Оно касается части установления ключей. Идентичность, состав группы, жизненный цикл ключей, безопасность конечных точек и реализация всё ещё требуют доказательств.
Какая схема быстрее?
В этой статье нет теста производительности, устанавливающего победителя. Измеряйте операции и развёртывание, важные для вашей группы.
