Порівнюйте вартість визначеної операції та докази щодо визначеної загрози, а не просто схему дерева зі схемою ключів відправників.
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, щоб усі учасники одночасно були онлайн?
Ні. Асинхронне використання — частина його дизайну. Застосункам усе одно потрібні політики для затриманих оновлень, застарілого стану й учасників, які довго перебувають офлайн.
Чи вирішує постквантове поширення ключів питання групової безпеки?
Ні. Воно стосується частини встановлення ключів. Ідентичність, склад групи, життєвий цикл ключів, безпека кінцевих точок і реалізація все ще потребують доказів.
Яка схема швидша?
У цій статті немає тесту продуктивності, що встановлює переможця. Вимірюйте операції та розгортання, важливі для вашої групи.
