Груповий обмін повідомленнями з ключами відправника може уникнути шифрування окремої копії кожного звичайного повідомлення для кожного одержувача. Відправник поширює ключовий матеріал захищеними попарними каналами, а потім використовує ланцюжок відправника для групових повідомлень. Це може зменшити повторювану роботу відправника із завантаження даних, але не робить загальну вартість доставки повідомлення незалежною від розміру групи.
Перш ніж порівнювати твердження про трафік, відокремте завантаження звичайних повідомлень, поширення ключів і доставку сервером.
Три види витрат усередині одного «групового повідомлення»
Розгляньмо спрощену групу з N учасників. Це пояснювальна модель, а не виміряний тест продуктивності Livara:
| Операція | Попарні копії повідомлення | Схема з ключами відправника |
|---|---|---|
| Відправник завантажує звичайний вміст | Можуть знадобитися окремі зашифровані копії для одержувачів | Після налаштування можна завантажити один груповий шифротекст |
| Установлення або поширення ключів | Попарні сеанси мають існувати та підтримуватися | Матеріал відправника має дістатися авторизованих одержувачів |
| Ретранслятор доставляє повідомлення групі | Одержувачам усе одно потрібні їхні копії | Одержувачам усе одно потрібні їхні копії |
| Зміни складу групи | Потрібно оновлювати сеанси та політику доступу | Може знадобитися повторне поширення свіжого матеріалу відправника |
«Сталий розмір завантаження відправника» описує одну частину цієї моделі. Це не означає сталого загального мережевого трафіку, нульових витрат на зміни складу чи однакової продуктивності на кожному пристрої.
Специфікація MLS, RFC 9420 IETF обговорює ефективність ключів відправника та додаткову роботу для відновлення безпеки після компрометації. MLS використовує інший підхід на основі дерева. Це архітектурна відмінність, а не рейтинг, що робить одну схему універсально найкращою.
Де постквантове встановлення ключів додає витрати
ML-KEM додає матеріал відкритого ключа та інкапсуляції, більший за поширені подання на еліптичних кривих. Але протокол не обов’язково має виконувати новий обмін KEM для кожного повідомлення. Налаштування, періодична зміна ключів і звичайне симетричне шифрування можуть мати різні витрати. NIST FIPS 203 визначає набори параметрів ML-KEM, а не повний формат передавання даних месенджера.
Саме тому множення розміру шифротексту KEM на «100 користувачів» саме собою не передбачає трафіку на повідомлення в чаті зі 100 учасників. Відповідь також залежить від повторного використання сеансів, оформлення повідомлень у мережеві блоки, пристроїв одержувачів, повторних передавань і того, чи вкладення завантажуються один раз, чи копіюються.
Коректне порівняння вказує кількість груп і пристроїв, розміри повідомлень та вкладень, частоту змін складу, збірку клієнта й умови мережі. Без цих подробиць точні цифри кілобайтів або витрат батареї можуть вводити в оману.
Що Livara говорить про LGS1
Сторінка безпеки Livara описує LGS1 як схему ланцюжків відправників для приватних груп. Ключовий матеріал кожного відправника поширюється всередині попарних сеансів LVR1; групові повідомлення використовують отриманий ланцюжок, а документація описує свіжі ключі відправників, коли учасники приєднуються або виходять.
Це задокументована архітектура постачальника, а не незалежно перевірений результат вимірювання продуктивності. Вона дає змогу пояснити задумане розділення поширення ключів і звичайних повідомлень. Вона не обґрунтовує тверджень, що кожне групове завантаження становить рівно 1,1 КБ, що вся система має вартість доставки O(1) або що витрати батареї виміряно як незначні.
Зміна ключів — частина бюджету безпеки
Видалення учасника з інтерфейсу недостатньо, якщо він досі має ключі, здатні розшифровувати майбутній трафік. Безпечний перехід має виключати видалені пристрої з поширення нових ключів і забезпечувати перехід решти клієнтів у правильний стан. Уже отримані повідомлення та скопійовані файли неможливо криптографічно відкликати.
Пряма секретність ключів відправника та відновлення після компрометації також залежать від просування ланцюжків ключів, видалення секретів і моменту введення свіжого матеріалу. Їх не слід виводити лише з використання постквантового KEM під час налаштування.
Запитання для практичної оцінки групового чату
- Звичайний текст завантажується один раз від відправника чи окремо для кожного пристрою одержувача?
- Які події змінюють ключі та що відбувається, поки учасник не в мережі?
- Як подано додані пристрої та видалених учасників?
- Чи захищені вкладення та ключі їх розшифрування тими самими правилами членства?
- Які метадані залишаються видимими ретранслятору?
- Чи відтворюються результати продуктивності на передбачених телефонах і в передбаченій мережі?
Модель загроз Livara розрізняє приватні групи та публічні канали й документує видиму інформацію маршрутизації. Публічні публікації та поширення ключів приватних груп не слід об’єднувати в одному твердженні про «зашифровані канали».
Ключі відправника можуть заощадити повторювану роботу. Корисне інженерне запитання — куди ця робота переміщується, які події змушують її повторювати та наскільки безпечно група змінює склад.
